W3C publiceert voorstel voor Web Neural Network-api voor browsers

De W3C-organisatie heeft een eerste versie uitgebracht van een voorstel voor een api voor een neuraal netwerk in de browser. De Web Neural Network-api moet het mogelijk maken de browser te gebruiken voor machine learning.

Een first draft van het voorstel staat inmiddels op de site van de standaardisatieorganisatie. Het document is opgesteld door de Web Machine Learning Working Group, die vorig jaar werd vastgesteld. Die groep bestaat onder andere uit Google, Microsoft en Intel.

De voorgestelde standaard moet WebNN gaan heten, of Web Neural Network. Het is een api die het mogelijk maakt om neurale netwerken te gebruiken vanuit de browser door gebruik te maken van hardwareacceleration-api's zoals WebGPU of WebGL. De W3C noemt als mogelijke toepassingen object- of gezichtsherkenningen, maar ook live-captioning, vertalingen of geluidsonderdrukking. Zulke toepassingen kunnen dan client-side worden uitgevoerd.

In het voorstel staan verschillende voorstellen rondom de beveiliging en privacyvoorwaarden voor de api. Die zou standaard uit moeten staan zodat niet iedere websitebeheerder er zomaar gebruik van kan maken zonder dat er permissies worden gegeven. Ook schrijft de api voor dat afbeeldingen en video's waarmee gerekend wordt alleen in de sandbox kunnen draaien.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (53)

Nou joepie, nog meer "vet" in webbrowsers.

En als het standaard uit moet staan vanwege de veiligheid, waarom moet het dan überhaupt de browser in?

Webdesigners zullen hun bezoekers dwingen om het voor hun website aan te zetten. Anders werkt de website gewoon niet.

[Reactie gewijzigd door RoestVrijStaal op 23 juni 2021 12:09]

Meestal werken deze API's op basis van permissie prompts die browser of het platform geeft. Denk aan de webcam persmissie die je voor je online videochat moet geven.

Het "waarom" hiervan is beschreven, voorbeelden worden geven zoals geluidsonderdrukking, handig tijdens diezelfde videochats.

Ik snap dat er kritiek op "vet" in de browsers maar de richting voor de browser als platform voor applicaties in plaats van document viewer is al lang ingezet. Je mag het ermee oneens zijn maar dit is slechts een ontwikkeling van dat platform en dus niet per se versassend.

Meestal werken deze API's op basis van permissie prompts die browser of het platform geeft. Denk aan de webcam persmissie die je voor je online videochat moet geven.

Ja, en de meeste mensen drukken op "OK"/ "Ja" / "Geaccepteerd", zonder te lezen. Want irritante popup. Tegenwoordig kun je beter van uit gaan dat eindgebruikers de domste mensen op aarde zijn, in plaats van vertrouwen op hun slimheid.

Nogmaals, het is een oplossing dat een probleem zoekt. Maar daardoor is het eigenlijk het probleem zelf.

De voorbeelden die worden aangedragen duidt op videoconferencing. Waarom zou dat per se in de browser moeten? Waarom niet een standalone applicatie?
Tegenwoordig heeft elke OS een app store waarin applicaties met twee klikken te installeren valt.

Ja, en de meeste mensen drukken op "OK"/ "Ja" / "Geaccepteerd", zonder te lezen. Want irritante popup. Tegenwoordig kun je beter van uit gaan dat eindgebruikers de domste mensen op aarde zijn, in plaats van vertrouwen op hun slimheid.

Dat gaat misschien op voor cookiewalls maar niet voor browser prompts, dit is een ander kaliber melding waar de website zelf geen controle over heeft. Die kan enkel een codepad inschrijven op een bepaalde keuze die kennelijk gemaakt is door de gebruiker, dit soort meldingen worden een stuk minder vaak doorgeklikt.

Waarom er steeds vaker applicaties voor een browser worden gemaakt is simpel: bereik. 1 codebase is ondersteund op je mobiel, tablet, laptop/Chromebook, desktop, en misschien ook nog wel je T.V. Waar het vaak lastig is om voor alle merken smartphones een app te maken en alle O.S.en te ondersteunen is het nog maar de vraag of je native code kan draaien op die T.V.

Los daarvan is het voor veel gebruikers simpeler om een meet link gemailed te krijgen en ze ready to go zijn. Anders gaan vergaderingen moeten wachten totdat iemand client X voor O.S. Y heeft geïnstalleerd in de hoop dat, dat werkt.

Nogmaals, de browser is al een applicatieplatform.

[Reactie gewijzigd door Ed Vertijsment op 23 juni 2021 12:45]

Sure, en whatsappfraude* komt ook voor, terug naar briefpost of...?

*En laten we hier even de privacy/messaging tool discussie achterwege laten.

[Reactie gewijzigd door Ed Vertijsment op 23 juni 2021 14:19]

Wij komen het inderdaad ook steeds vaker tegen push notificaties met malafide intenties. Bijv het stalken van de gebruiker terwijl de browser inactief is.
Je kan er dus vergif op innemen dat deze functie op zelfde manier misbruik of anders gezecht met de verkeerde intenties gebruikt gaat worden
https://blog.malwarebytes...ns-feature-asking-abused/

The Notifications API lets a web page or app send notifications that are displayed outside the page at the system level; this lets web apps send information to a user even if the application is idle or in the background. This article looks at the basics of using this API in your own apps.

[Reactie gewijzigd door xbeam op 24 juni 2021 12:33]

Waarom niet een standalone applicatie?
Tegenwoordig heeft elke OS een app store waarin applicaties met twee klikken te installeren valt.

Ik ben juist anti app.... waarom nou voor alles een app terwijl 95% niet meer is dan een simpele html wrapper? Ook op mijn mobiel gaat mijn voorkeur uit naar mobiele sites tov apps

Voor veel toepassingen is dat waar. Die zijn (kort door de bocht) niet meer dan wat html, css en plaatjes, op een rijtje gezet aan de hand van een paar regels, op maat aangeroepen uit een database.

Maar dit gaat wat verder. Gezichtsherkenning, ruisonderdrukking functies etc kost veel rekentijd, dus vraagt veel van de accu. Juist op je mobieltje, laptop, tablet wil je daarom rechtstreeks gebruik maken van de api’s van het OS, want dat is veel efficiënter dan alles naar het javascript van de browser omzetten en daar in werken.

Cc @Ed Vertijsment Helemaal eens dat het ideaal zou zijn vanuit ontwikkelaars-perspectief om alles in één code-base te schrijven. Dat hadden we al eens: Flash. Alleen lukte het niet zo goed om dat veilig te houden. Dat zal ook hier weer de grootste uitdaging zijn, vrees ik.

Flash had natuurlijk ook andere problemen (UX en stroomverbruik om waar wat te noemen) waardoor het focus (ontwikkeltijd) verloor, daarnaast zorge het feit dat het uit de tijd van veiligheid komt achteraf wel komst zorgde voor veel legacy security issues.

Browsers hebben een veel beter track record wat betreft sandboxing, en kunnen qua code uitvoeren juist veel minder dan native apps. Het is dus absoluut geen argument om dan maar platform specifieke toepassingen te gaan schrijven.

[Reactie gewijzigd door Ed Vertijsment op 23 juni 2021 14:22]

Als er ooit één gereedschap is geweest wat flexibel was qua UX, is het Flash dus ik ben benieuwd wat daar aan schortte.

Browsers hebben een veel beter track record wat betreft sandboxing.

Tja, browsers konden vaak nog niet 1% van wat Flash kon, dus dat kun je niet vergelijken. Hele 3D-engines kon je in Flash aanroepen. In principe kon je er een compleet OS in bouwen.

Browsers […] kunnen qua code uitvoeren juist veel minder dan native apps. Het is dus absoluut geen argument om dan maar platform specifieke toepassingen te gaan schrijven.

Als iets in een browser niet kan, blijft er toch weinig anders over dan een platform-specifieke app?

Als er ooit één gereedschap is geweest wat flexibel was qua UX, is het Flash dus ik ben benieuwd wat daar aan schortte.

Meeschalen met de container size, om maar wat te noemen. Best belangrijk als je content geschikt wil maken voor een (smart) telefoon.

Tja, browsers konden vaak nog niet 1% van wat Flash kon, dus dat kun je niet vergelijken. Hele 3D-engines kon je in Flash aanroepen. In principe kon je er een compleet OS in bouwen.

Vroeger niet nee, dus flash had toen een goede functie maar is echter nu gepensioneerd en de taken zijn vervangen door browsers zelf. En ja, je kunt nu ook 3d engines aanroepen in JS. En of het nou echt een goed idee om een compleet OS er in te kunnen bouwen?

Als iets in een browser niet kan, blijft er toch weinig anders over dan een platform-specifieke app?

De standaard wordt dan ook doorontwikkeld met nieuwe features zodat er steeds meer wel kan. En aangezien dit nu bedacht is neem ik aan dat de meeste echt nuttige dingen al wel kunnen

(over wat er schortte aan de user experience)
Meeschalen met de container size, om maar wat te noemen. Best belangrijk als je content geschikt wil maken voor een (smart) telefoon.

Apple liet Flash nooit toe op iOS en verder kon je gewoon 100% het scherm gebruiken, uitlezen hoe groot het was etc, dus dat was het probleem niet.

Vroeger niet nee, dus flash had toen een goede functie maar is echter nu gepensioneerd en de taken zijn vervangen door browsers zelf.

Het is altijd simpelweg geweigerd door Apple en daardoor alleen al viel het af als optie voor webapps. Uiteindelijk was het vooral een politieke strijd die Adobe nooit kon winnen, want compleet afhankelijk van een goede relatie met Apple. Dus ja, Adobe heeft zelf het bijltje erbij neergegooid. Ze hebben nu 80 applicaties die ze los verkopen en dat levert veel meer op dan Flash ooit deed, dus ze vinden het wel prima.

Maar de taken zijn nauwelijks echt overgenomen. In Flash kon je veel sneller iets bouwen, onderdelen hergebruiken, je kon veel beter zien wat je aan het bouwen was dan in javascript etc. De webdesigner app van Google kan maar een fractie van wat Flash kon, puur een paar van de meest noodzakelijke opties. (fade in, fade out, beweeg plaatje van a naar b in x seconden.

En ja, je kunt nu ook 3d engines aanroepen in JS.

Alleen zijn die veel 'duurder' qua rekentijd, want niets kan native, alles moet via een omweg. Kortom je batterij is sneller leeg en je telefoon wordt er vooral warm van.

En of het nou echt een goed idee om een compleet OS er in te kunnen bouwen?

Nee, maar het zegt wel iets over hoe de verhoudingen liggen.

De standaard wordt dan ook doorontwikkeld met nieuwe features zodat er steeds meer wel kan. En aangezien dit nu bedacht is neem ik aan dat de meeste echt nuttige dingen al wel kunnen

Wat mij betreft wel maar het W3 consortium wil blijkbaar nog een stapje verder. Ik ben niet zo paniekerig qua privacy en zo maar ik vraag me af of je dit aan je browser wil toevertrouwen. Ik zie Apple dit bijvoorbeeld nog niet toelaten, zaken als doorlopend de video + audio van de camera door Chrome laten bekijken, alleen maar om te zien of de gebruiker de kamer uitloopt.

Het is veel logischer, efficiënter en veiliger de api's van het OS daarvoor in te zetten. Ik verwacht eerder dat daar een koppeling richting browser voor komt, dan dat de browser alles zelf mag gaan doen.

[Reactie gewijzigd door laptopleon op 23 juni 2021 17:40]

Apple liet Flash nooit toe op iOS en verder kon je gewoon 100% het scherm gebruiken, uitlezen hoe groot het was etc, dus dat was het probleem niet.

Maar je kon niet (makkelijk) “flow” content schrijven zoals dat in CSS kan, niet iedereens hobby maar veel expressiever en sneller dan een canvas dynamisch herschalen en invullen, de praktijk was dan ook dat gewoon niet gedaan werd.

In die tijd had ik een Android telefoon, en die kon wel flash content afspelen, dat ging allerminst soepel: heel traag om te laden en lage FPS, dat gezien hebbende was het niet heel gek dat Apple dat niet zag zitten op iOS (wat toen nog volledig op webapps inzette)

Flash had een functie toen browsers nog minder ver waren maar het werd al vrij snel ingehaald. Er is een tijd geweest waar er voor bepaalde dingen in flash geen alternatief was maar dat is nu wel ingehaald.

Los van dit alles voldeed flash niet aan moderne eisen: niet goed indexeerbaar en allerminst toegankelijk, allemaal redenen om naar alternatieven te zoeken.

Alleen zijn die veel 'duurder' qua rekentijd, want niets kan native, alles moet via een omweg. Kortom je batterij is sneller leeg en je telefoon wordt er vooral warm van.

Draait gewoon op de hardware hoor, net zoals flash. Was je telefoon dan wss ook wel warm van geworden.

[...]
Maar je kon niet (makkelijk) “flow” content schrijven zoals dat in CSS kan, niet iedereens hobby maar veel expressiever en sneller dan een canvas dynamisch herschalen en invullen, de praktijk was dan ook dat gewoon niet gedaan werd.

In Flash kon je wel makkelijk een tekstkader vol laten lopen met tekst, zelfs nog met wat html-opmaak zoals <b> en een a href / link en dat tekstkader kon je ook nog redelijk makkelijk verplaatsen en zo, maar afbeeldigen er in laten floaten – dat is wat je bedoelt neem ik aan – dat ging niet zomaar. Je kon wel images importeren en positioneren/manipuleren maar het probleem was dat je niet precies wist hoe de html-tekst ging afbreken / hoe lang het werd.

In de tijd dat Flash populair was, werkte ik voor reclamebureau's. Zowel opdrachtgevers als art directors, vormgevers en consumenten waren gewend dat een kop en andere teksten tot op de millimeter binnen een optimale, vooraf bepaalde en goedgekeurde vorm werd gezet, die daarna nooit meer veranderde. Tenzij bewust.

Hoewel in html sinds dag één de tekstkaders wél konden meerekken met het window, werd dat maar zelden toegepast, omdat je dan veel minder controle had over hoe je pagina er uit kwam te zien: Bij de een zou de kop op één regel passen, bij de ander ineens niet meer. Bij de één zou een plaatje 'mooi' net zo lang zijn als de kolom tekst er naast, bij een iets andere windowbreedte, browserversie, groter ingestelde standaardlettergrootte, geïnstalleerd font kon het zomaar een paar regels te kort of te lang worden.

Eigenlijk is dat voor een vormgever natuurlijk helemaal niet handig. Die wil geen verrassingen. Die wil juist controle tot op de pixel. Dus dat Flash geen floating css had, dat vonden de meeste vormgevers en opdrachtgevers bepaald niet erg

In die tijd had ik een Android telefoon, en die kon wel flash content afspelen, dat ging allerminst soepel: heel traag om te laden en lage FPS, dat gezien hebbende was het niet heel gek dat Apple dat niet zag zitten op iOS (wat toen nog volledig op webapps inzette)

Als ik me goed herinner, was er een speciale 'mobile' versie van Flash, maar die is nooit verder gekomen dan een enorm versimpelde variant.

Het is echt totale onzin dat Flash niet op een iPhone of iPad zou kunnen draaien. Sowieso waren de meeste Flash creaties banners, die niet groter mochten zijn dan 15 tot 35 kilobyte, afhankelijk van het formaat van de banner. Een paar plaatjes en een paar strookjes tekst die elkaar afwisselden, misschien nog een postscript-achtig logootje, dat niveau.

Daar draaide dan meestal nog een stukje actionScript in – wat als twee druppels op javascript lijkt – om een paar oersimpele dingetjes te regelen zoals drie keer de banner laten loop-en en als er iemand op klikte, een javascript aanroepen om een link te openen.

Kortom, van negen van de tien Flash-banners deden nauwelijks iets qua rekenkracht. Zeker niet als je dat vergelijkt met een écht videobestand afspelen zoals een youtube-filmpje kijken.

Geen enkele 'vroege' iPhone of iPad had ooit moeite met het afspelen van een mp3 of mp4, maar een Flash banner met een paar simpele sprites zou teveel gevraagd zijn… Sorry, maar dat gelooft echt niemand die een beetje met deze materie bekend is.

Een iPhone had al gauw meer rekenkracht dan wat nog niet zo lang daarvoor een 'supercomputer' heette. De PowerMac G4 mocht in 1999 niet geëxporteerd worden naar bepaalde landen vanwege de 'gevaarlijke' rekenkracht van wel 1 gigaflop. De iPhone X deed al 600 gigaflops.

Apple wilde gewoon niet dat mensen apps in Flash gingen maken omdat ze veel liever zagen dat er apps voor kwamen in de App Store, gebaseerd op iOS api's — want hoe meer apps van 'derden' ontwikkelaars = hoe aantrekkelijker iOS en het Apple ecosysteem voor gebruikers. En ik begrijp dat ook wel hoor, want op de inhoud van de App Store kan Apple controle uitoefenen. Op Flash apps die online staan zouden ze nul controle hebben. Die wil je geen toegang geven tot camera en privé-gegevens via elke website die Flash bevat. (Maar zeg dat dan gewoon.)

Flash had een functie toen browsers nog minder ver waren maar het werd al vrij snel ingehaald. Er is een tijd geweest waar er voor bepaalde dingen in flash geen alternatief was maar dat is nu wel ingehaald.

Deels klopt dat, zoals dat er nu een video canvas object is in html, maar deels zijn die alternatieven er in de praktijk gewoon niet. Banners zijn nu meestal veel simpeler. De 'betere' banners zijn nu gewoon een videootje of een sjabloon in javascript waar een ander tekstje / plaatje in geladen worden. Maar het 'wat gaan we deze week nou weer voor animatie verzinnen' / creatieve format is bij lange na niet meer van het niveau van die tijd.

Los van dit alles voldeed flash niet aan moderne eisen: niet goed indexeerbaar en allerminst toegankelijk, allemaal redenen om naar alternatieven te zoeken.

Flash werd beter geïndexeerd dan veel mensen denken. Google las de .swf uit, op zoek naar teksten. Soms scoorden Flash sites beter dan html. Later heeft Google dat steeds meer teruggeschroefd.

Hoewel je hele sites in Flash kon maken, is dat nooit echt heel populair geweest. Flash is goed voor animaties en spelletjes en zo. Daar konden slechtzienden toch al niet veel mee.

[over 3d engines via Flash dan wel via javascript gebruiken]

Draait gewoon op de hardware hoor, net zoals flash. Was je telefoon dan wss ook wel warm van geworden.

Het draait wel maar kan een enorm verschil uitmaken of iOS een api heeft waarmee een app (zoals een Flash app / plugin) een of twee implementatie-lagen kan overslaan en bij wijze van spreken rechtstreeks bij de gpu of geluids-chip kan.

Apple is daar overigens heel goed in; het optimaliseren van hardware én software. Het grote voordeel van Apple is dat ze zowel de hardware als software volledig zelf kunnen bepalen, zeker op de iPhone waar ze zelf het chipontwerp bepalen. OK, nu gaan ze dat dus ook op de desktop doen maar dat is pas recent.

Op de iPhone / iPod / iPad doen ze dat al vanaf het begin. Nog een reden dat Flash daar in meegenomen had kunnen worden. Maar dat kwam politiek en strategisch niet uit.

(...)

Hoewel in html sinds dag één de tekstkaders wél konden meerekken met het window, werd dat maar zelden toegepast, omdat je dan veel minder controle had over hoe je pagina er uit kwam te zien: Bij de een zou de kop op één regel passen, bij de ander ineens niet meer. Bij de één zou een plaatje 'mooi' net zo lang zijn als de kolom tekst er naast,

We hebben het over de tijd dat CSS3 opkwam, media queries zijn intrede deden, en je op eens op je smartphone zat te browsen en (believe it or not) Safari de superieure browser was. De browser zelf had nu handvaten om pagina's neer te zetten die overal mee schaalden binnen restricties van de ontwikkelaar/ontwerper. Die mechanismes had flash niet (fatsoenlijk).

bij een iets andere windowbreedte, browserversie, groter ingestelde standaardlettergrootte, geïnstalleerd font kon het zomaar een paar regels te kort of te lang worden.

Ik zak dat je het woord "flexibel" gebruikte bij flash en ux, je bedoelt dus dat je de gebruikers voorkeuren (voor bijvoorbeeld toegankelijkheid) negeert omdat een paar kunstenaars er niet mee om konden gaan? Toegankelijkheid is een (belangrijk) ding, en flash was er heel slecht in.

Sidenote: tegenwoordig is het de kunst om in logica uit te drukken wat een design "kloppend" maakt en die regels goed te declareren in plaats van op de pixel zelf te gaan zitten, with good reason: want je weet niet hoeveel pixels je hebt of hoe veel een stuk tekst nodig heeft, om nog maar te zwijgen over right to left teksten.

Eigenlijk is dat voor een vormgever natuurlijk helemaal niet handig. Die wil geen verrassingen. Die wil juist controle tot op de pixel. Dus dat Flash geen floating css had, dat vonden de meeste vormgevers en opdrachtgevers bepaald niet erg

Maar wel voor de gebruikers, toegankelijk en ervaring. Alles was eigenlijk brak behalve het ego van de marketing en de mogelijkheden voor bepaalde specifieke dingen om iets meer te doen.

Als je geen verassingen wil moet je een poster ontwerpen en zelf uitprinten. Maar geen website ontwerpen. Er is simpelweg geen garantie dat hoe jij het ontworpen hebt er exact ook zo uit komt te zien. En dat is een goed iets, want geen gebruiker is het zelfde en browsers kunnen daar rekening mee houden.

Het denken in een "canvas" waarin de afmetingen vooraf bekend waren is met de komst van een resolutie op het web, anders dan 800x600 of 1024*768, verouderd. En een van de redenen waarom flash niet meer mee kon (en er dus een ander pad in werd geslagen) was omdat het hier niet goed mee om kon gaan. Dit is overigens nog steeds een probleem: Veel designers weten nog steeds niet hoe je ontwerpt voor een scherm ten opzichte van en "print", flash is in zekere zin on print on steroids, maar niet gelijk aan een ontwerp voor schaalbare (scherm) omgeving.

Ja, er is een transitieperiode geweest waar niet alles wat flash kon door de browser zelf kon. Maar noem mij 1 ding dat tegenwoordig die browser niet kan wat flash wel kon. Hooguit is de tooling minder, maar niets houd je tegen om zelf de code te schrijven.

Het is echt totale onzin dat Flash niet op een iPhone of iPad zou kunnen draaien. Sowieso waren de meeste Flash creaties banners, die niet groter mochten zijn dan 15 tot 35 kilobyte, afhankelijk van het formaat van de banner. Een paar plaatjes en een paar strookjes tekst die elkaar afwisselden, misschien nog een postscript-achtig logootje, dat niveau.

Daar draaide dan meestal nog een stukje actionScript in – wat als twee druppels op javascript lijkt – om een paar oersimpele dingetjes te regelen zoals drie keer de banner laten loop-en en als er iemand op klikte, een javascript aanroepen om een link te openen.

Kortom, van negen van de tien Flash-banners deden nauwelijks iets qua rekenkracht. Zeker niet als je dat vergelijkt met een écht videobestand afspelen zoals een youtube-filmpje kijken.

Geen enkele 'vroege' iPhone of iPad had ooit moeite met het afspelen van een mp3 of mp4, maar een Flash banner met een paar simpele sprites zou teveel gevraagd zijn… Sorry, maar dat gelooft echt niemand die een beetje met deze materie bekend is.

Ik denk dat je het rooskleuriger voorsteld dan dat het was. In de praktijk kwam een flash banner na een paar minuten garbled en zwaar compressed opdagen met een framerate van een paar frames per seconden. Wellicht omdat de rekenkracht verdeeld moest worden tussen het OS zelf, de browser en dan nog een keer de plugin. Een flash file op het device zelf draaide wellicht beter maar had weer 0 bereik.

Qua video: dat werd vaak overgelaten aan het OS, daar hoefde de browser dus niets mee en profiteerden van de optimalisaties van de OS leverancier, daarnaast: als ik me het goed herinneren (moest je wel al je video's dubbel endoden per OS) hadden deze apparaten al heel snel hardware decoding hiervoor.

Qua actionscript: goeie kans dat in die tijd actionscript superieur was aan javascript, laatst toevallig stukje over gelezen. Ze gebruikten volgens mij een niet officieel gestandaardiseerde uitegebreidere specificatie.

Apple wilde gewoon niet dat mensen apps in Flash gingen maken omdat ze veel liever zagen dat er apps voor kwamen in de App Store, gebaseerd op iOS api's — want hoe meer apps van 'derden' ontwikkelaars = hoe aantrekkelijker iOS en het Apple ecosysteem voor gebruikers. En ik begrijp dat ook wel hoor, want op de inhoud van de App Store kan Apple controle uitoefenen. Op Flash apps die online staan zouden ze nul controle hebben. Die wil je geen toegang geven tot camera en privé-gegevens via elke website die Flash bevat. (Maar zeg dat dan gewoon.)

In deze tijd had Apple nog geen App Store en zetten ze nog in op webapps. Apple is wel heel restrictief op gebruikerservaring. Eentje die flash (daar) niet kon bieden.

Deels klopt dat, zoals dat er nu een video canvas object is in html, maar deels zijn die alternatieven er in de praktijk gewoon niet. Banners zijn nu meestal veel simpeler. De 'betere' banners zijn nu gewoon een videootje of een sjabloon in javascript waar een ander tekstje / plaatje in geladen worden. Maar het 'wat gaan we deze week nou weer voor animatie verzinnen' / creatieve format is bij lange na niet meer van het niveau van die tijd.

Dat laatste wil ik geloven maar daar is geen technische reden voor. Kan ook zijn dat er minder tijd in gestoken wordt, is toch ad-block voer.

Flash werd beter geïndexeerd dan veel mensen denken. Google las de .swf uit, op zoek naar teksten. Soms scoorden Flash sites beter dan html. Later heeft Google dat steeds meer teruggeschroefd.

Ik denk dat je dat overschat, Google kan ook JavaScript indexeren, in de praktijk kan je er niet vanuit gaan en werkt het meestal niet. Indexeren is/was niet van hetzelfde niveau en was eigenlijk niet zoveel meer dan een zoekhoudertje.

Hoewel je hele sites in Flash kon maken, is dat nooit echt heel populair geweest. Flash is goed voor animaties en spelletjes en zo. Daar konden slechtzienden toch al niet veel mee.

Ja, flash was goed in spelletjes. Maar eerlijk is eerlijk, niet goed in websites.

Het draait wel maar kan een enorm verschil uitmaken of iOS een api heeft waarmee een app (zoals een Flash app / plugin) een of twee implementatie-lagen kan overslaan en bij wijze van spreken rechtstreeks bij de gpu of geluids-chip kan.

Browsers zijn zwaar geoptimaliseerd en if any geven je heel weinig overhead qua graphics. webgl (en opkomend webgpu) zitten al relatief dicht bij de gpu en ik moet de eerste benchmark waaruit blijkt dat het een probleem is nog zien.

Of je direct bij de hardware moet kunnen weet ik niet, wet hadden het over security enzo.

In 1997 kon je pas lokaal inbellen met je modem, in Nederland. Zelfs jaren later toen ADSL gangbaar was geworden waren websites in de praktijk net zo statisch als een krant. Het was al heel wat, als er een animated gifje te zien was. <blink> en <marquee>Dit is een lichtkrant</marquee> waren populair om je site 'op te leuken'. Het was niet veel spannender dan email lezen.

Als je dan ziet wat voor baksteen in de vijver Flash was… Ineens kon er van alles. Niet alleen kon je minutenlange animaties maken à la cartoon-net die laadden terwijl ze speelden, dus zonder wachttijd, maar bijvoorbeeld ook logo's en tekeningen konden schermvullend groot zijn en toch een minimum aan download-tijd kosten – want dat was dé grote bottleneck.

Alleen al vanwege die postscript-achtige mogelijkheden was Flash een openbaring. Dat vinden we nu allemaal zo doodnormaal dat we er niet eens bij stilstaan.

Je had heus wel andere plugins die bijvoorbeeld video konden laten zien, maar omdat elk OS / browser het wiel opnieuw ging uitvinden, was er jarenlang geen standaard. Dus toen Flash een standaard mee-geïnstalleerde plugin werd, kon je eindelijk wel zeker weten dat praktisch iedereen je video kon zien. YouTube had nooit zo vroeg / zo groot geworden zonder Flash. Niet voor niets hebben die Flash pas heel laat losgelaten.

Kijk, ik pas er voor om als een soort verzuurde Flash-fanaat krampachtig vijf kantjes vol te schrijven met verweer Maar focussen op een paar zaken waar Flash minder handig voor was, is de zaak omdraaien.

Er is simpelweg geen garantie dat hoe jij het ontworpen hebt er exact ook zo uit komt te zien. En dat is een goed iets, want geen gebruiker is het zelfde en browsers kunnen daar rekening mee houden.

Kijk, dit klinkt voor sommigen misschien heel romantisch of zo – 'geen gebruiker is hetzelfde' en 'browsers kunnen daar rekening mee houden' – maar die gebruiker wil gewoon zijn pagina een beetje fatsoenlijk kunnen lezen en een browser houdt nergens rekening mee. Jij als vormgever moet zelf de viewporten kiezen en hoe je de elementen dan neerzet.

In de praktijk zie je dat vormgevers meestal maar drie maten kiezen: smartphone, tablet en deskstop. Bij de tussenliggende formaten schuiven de elementen op percentage daartussen. Niet alleen is dat veel meer werk voor de vormgever, het beperkt ook de bruikbare opties en dan nóg kom je als lezer regelmatig voor onhandige situaties te staan, omdat tekst voor cruciale delen van de achtergrond vallen qua plaatje of zo.

Dus dit heeft weinig met Flash te maken. Flash gebruik je sowieso niet om een hele site te bouwen, zoals je al zei, maar voor losse elementen.

Wat fonts betreft: Juist Flash maakte het mogelijk om eens een ander font te gebruiken dan de standaard handjevol 'websafe' fonts, tien, vijftien jaar voordat er een breed geaccepteerde standaard voor webfonts via css was.

Browsers zijn zwaar geoptimaliseerd en if any geven je heel weinig overhead qua graphics. webgl (en opkomend webgpu) zitten al relatief dicht bij de gpu en ik moet de eerste benchmark waaruit blijkt dat het een probleem is nog zien.

Dit is precies mijn punt. Daar had Flash dus ook gebruik van kunnen maken. Nu wordt geroepen dat Flash een batterij-killer was terwijl het simpelweg nooit toegang kreeg tot dergelijke techniek. Het was nooit een gelijk speelveld.

In 1997 kon je pas lokaal inbellen met je modem, in Nederland. Zelfs jaren later toen ADSL gangbaar was geworden waren websites in de praktijk net zo statisch als een krant. Het was al heel wat, als er een animated gifje te zien was. <blink> en <marquee>Dit is een lichtkrant</marquee> waren populair om je site 'op te leuken'. Het was niet veel spannender dan email lezen.

Als je dan ziet wat voor baksteen in de vijver Flash was… Ineens kon er van alles. Niet alleen kon je minutenlange animaties maken à la cartoon-net die laadden terwijl ze speelden, dus zonder wachttijd, maar bijvoorbeeld ook logo's en tekeningen konden schermvullend groot zijn en toch een minimum aan download-tijd kosten – want dat was dé grote bottleneck.

Kijk, ik pas er voor om als een soort verzuurde Flash-fanaat krampachtig vijf kantjes vol te schrijven met verweer Maar focussen op een paar zaken waar Flash minder handig voor was, is de zaak omdraaien.

Ik snap dat, ik zeg ook niet dat flash geen waarde had (zeker in het begin van het web), maar we hadden het erover dat er mee dan alleen de security issues meespeelde in de beweging weg van flash. de nadelen werden gewoon groter dan de voordelen (die het ook had).

Toen er meer resoluties gangbaar werden, mobiel gebruik opkwam, werd al vrij snel duidelijk dat flash daar niet goed in kon faciliteren. En nee, mobiel gebruik was zoals eerder gezegd echt niet zo rooskleurig als dat je het schetste. Of dat nou door de implementaties van de fabrikanten kwamen, of door een überhaupt zware runtime (voor de hardware van toentertijd) weet ik niet maar in de praktijk was flash gewoon geen beste keuze als je mobiel wou ondersteunen, of toegankelijkheid hoog in het vaandel had staan.

Kijk, dit klinkt voor sommigen misschien heel romantisch of zo – 'geen gebruiker is hetzelfde' en 'browsers kunnen daar rekening mee houden' – maar die gebruiker wil gewoon zijn pagina een beetje fatsoenlijk kunnen lezen en een browser houdt nergens rekening mee. Jij als vormgever moet zelf de viewporten kiezen en hoe je de elementen dan neerzet.

Maar dan negeer je mensen die hun lettergrootte even iets groter zetten, of een screenreader gebruiken. Allemaal dingen waar flash meestal niet lekker mee omging (of de browsers die de plugin draaiden).

In de praktijk zie je dat vormgevers meestal maar drie maten kiezen: smartphone, tablet en deskstop. Bij de tussenliggende formaten schuiven de elementen op percentage daartussen. Niet alleen is dat veel meer werk voor de vormgever, het beperkt ook de bruikbare opties en dan nóg kom je als lezer regelmatig voor onhandige situaties te staan, omdat tekst voor cruciale delen van de achtergrond vallen qua plaatje of zo.

De kunt hier is dus om zo goed mogelijk regels in te richten die afdwingen wat kloppend is en anders na te denken over wat een design is. Een scherm is geen print en de afmetingen zijn simpelweg onbekend, daar zul je dus goed over moeten nadenken.

Als ik nu een fixed formaat neerzet voor een webpagina van 800x600 kan ik daar binnen alles pixel perfect maken maar dat gaat niet lekker werken op mobiel nog desktop. Ik kies er dan voor om iets te maken dat op alle resoluties sense maakt. Ik zal dus anders moeten nadenken.

Een ontwerp voor een website is fundamenteel iets anders dan voor print of een canvas, dat zul je dus ook anders moeten benaderen. Als je als lezer voor onhandige situaties komt te staan heb je een bug gevonden.

Wat fonts betreft: Juist Flash maakte het mogelijk om eens een ander font te gebruiken dan de standaard handjevol 'websafe' fonts, tien, vijftien jaar voordat er een breed geaccepteerde standaard voor webfonts via css was.

Oh, dat weet ik nog. Van die scripts die runtime een html kop (voor indexeerbaarheid) verving voor een flash file met een custom font. Dat was voordat we webfonts konden gebruiken een manier inderdaad.

Dit is precies mijn punt. Daar had Flash dus ook gebruik van kunnen maken. Nu wordt geroepen dat Flash een batterij-killer was terwijl het simpelweg nooit toegang kreeg tot dergelijke techniek. Het was nooit een gelijk speelveld.

Maar je wilt toch niet een browser plugin toegang geven om code direct uit te voeren op de hardware? Dus dan is het iets wat de sandbox moest leveren. Volgens mij deed het dat overigens ook, zowel flash als js waren prima capabel om met goede performance 3d dingen te doen.

Al met al is de reden dat er van flash afgeweken ging worden niet per se de veiligheidsissues geweest. Er zaten heel veel andere nadelen aan die met name moderne toepassingen in de weg zaten. Waar het ooit vernieuwend was werd het eenvoudigweg ouderwets.

[Reactie gewijzigd door Ed Vertijsment op 24 juni 2021 15:20]

Tja, javascript is nog veel ouder en dat wordt nog volop gebruikt, sterker nog, dat vult grotendeels het gat wat Flash achterliet. Maar toch zegt nooit iemand… javascript, wat ouderwets, zijn in het verleden veiligheidsissues mee geweest.. laten we daar maar mee stoppen.

Een deel van dat gat is gedicht doordat men genoegen neemt met minder mogelijkheden. Je ziet zelden of nooit interactieve banners meer.

De wereld is veranderd en blijkbaar kunnen we zonder, maar ik mis de opties die het bood.

Tja, javascript is nog veel ouder en dat wordt nog volop gebruikt, sterker nog, dat vult grotendeels het gat wat Flash achterliet. Maar toch zegt nooit iemand… javascript, wat ouderwets, zijn in het verleden veiligheidsissues mee geweest.. laten we daar maar mee stoppen.

Absoluut, in js engines komen ook lekken voor, en de taal is absoluut niet perfect (de laatste versie van actionscript was uitgebreider dan de huidige versie van javascript/ecmascript volgens mij). Maar de api's zijn veel verder gekomen en samen met de omliggende technieken is het wel bij met wat flash kon.

Javascript is ergens ook ouderwets, maar wel continu onderhouden (samen met de rest van de omliggende technieken) en daarom nog wel bij, simpelweg omdat er nog steeds brood wordt gezien in de richting die het gaat.

Een deel van dat gat is gedicht doordat men genoegen neemt met minder mogelijkheden. Je ziet zelden of nooit interactieve banners meer.

De wereld is veranderd en blijkbaar kunnen we zonder, maar ik mis de opties die het bood.

Maar dat zijn niet de (technische) mogelijkheden. Ik denk vooral de trend van bannermoeheid en het gebruik van adblockers simpelweg de waarde (en dus de investeringen) erin verminderen, dat in combinatie van de duurdere kosten om ze opnieuw te leren maken zal misschien netto minder van deze uitingen opleveren. Dat je het mist, kan ik vreemd genoeg ergens begrijpen. Het kan nog steeds, al vraag ik me af of veel mensen er voor willen betalen.

Het kan eigenlijk niet meer, want de Flash plug-in wordt niet meer standaard geïnstalleerd, er wordt zelfs actief gepusht vanuit Adobe om hem te verwijderen (pop-ups met klik hier om te verwijderen etc). Dit is al een hele tijd bezig. Plus dat iOS het niet ondersteunt.

Je kan er wel een javascript ding van maken hoor, vanuit Adobe Flash, als je dat nog hebt. Dat werkt aardig.

Wat betreft bannermoeheid.. Mensen vonden banners altijd al irritant hoor Maar het plaatsen van al die irritante banners betaalde intussen natuurlijk wel voor ‘gratis’ content zoals tweakers.net etc.

Ik denk dat de creativiteit en opvallendheid van banners nu ook minder belangrijk is omdat er veel gerichter geplaatst wordt op Facebook, via Google etc kortom aan de hand van profielen.

Als TomTom een reclamecampagne deed, zetten ze gewoon een week lang banners bij alle grote sites in heel Europa. Dat zie je nu niet meer.

Ik denk dat die verandering inderdaad gewoon meer te zoeken is in de reclame industrie zelf in plaats van in de techniek. Creatieve uitingen hebben plaatsgemaakt voor engineered ads. Ik weet niet welke ik irritanter vindt maar ik neig naar het laatste.

... En heeft datzelfde OS ook dezelfde prompts om voor iedere iets verder gaand gebruik van b.v. camera, microfoon of locatie toestemming te vragen van de gebruiker.

Ja, en de meeste mensen drukken op "OK"/ "Ja" / "Geaccepteerd", zonder te lezen. Want irritante popup. Tegenwoordig kun je beter van uit gaan dat eindgebruikers de domste mensen op aarde zijn, in plaats van vertrouwen op hun slimheid.

Dit is niet waar. Een snelle blik in onze (Chrome) statistieken vertelt me dat minder dan een vijfde van de aanvragen geaccepteerd wordt.

Ja, aanvragen zijn vervelend, waardoor alle browsers blijven innoveren over de weergave, maar ook de vraag óf aanvragen überhaupt weergegeven moeten worden. (Bijvoorbeeld op basis van eerdere keuzes, alsmede keuzes van grotere aantallen gebruikers.)

Waarom geen standalone applicatie? Omdat sommige mensen Teams gebruiken, anderen Zoom, of Facebook Meet, of Google Hangouts / Meet, or Skype, of één van de andere mogelijkheden. Elke applicatie die je installeert heeft een impact op je privacy. Een browser kan garanderen dat dit eindigt zodra je de tab sluit—met een nadrukkelijke uitzondering van notificaties.

Ik vindt houdt rekening met de slimme bescherm de slimme tegen de domme en laat de domme de gevolgen van hun daden ervaren ze mogen niet slim worden ze moeten slim worden

Het duurt nog even, maar over een tijd draai jij bijna geen native applicaties meer. Alles draait dan in je browser. Dit soort API's helpen om dit doel te bereiken.

Strikt genomen bestaat een neuraal netwerk uit zenuwbanen in mens en dier. Men zal wel een kunstmatige versie bedoelen, maar is dan het verschil met 'gewone' computers? Blijft op deze manier nogal vaag wat er bedoeld wordt, laat staan wat je browser er mee moet.

De voorbeelden in de draft maakt toch veel duidelijk. Bijvoorbeeld:

A user opens a web-based video conferencing application, but she temporarily leaves from her room. The application is watching whether she is in front of her PC by using object detection (for example, using object detection approaches such as [SSD] or [YOLO] that use a single DNN) to detect regions in a camera input frame that include persons. When she comes back, the application automatically detects her and notifies other online users that she is active now.

Je kan je browser dus leren om mensen te detecteren. Een ander voorbeeld gaat nog verder waardoor een browser ook mensen kan herkennen.

Er is geen verschil... tenminste dat is mijn beeld. Dit soort cores, insteek kaarten etc zijn alleen heel goed in deze specifieke taak terwijl de traditionele cpu een beetje goed is in alles

Wat ik grappig vind is dat we (als in de wereld) jaren geleden juist zijn gaan centraliseren in een CPU terwijl je de laatste 20 jaar weer decentralisatie ziet (eerst alleen gpu's maar tegenwoordig echt van alles).

[Reactie gewijzigd door Mellow Jack op 23 juni 2021 13:23]

Ik zie niet zo’n centraliseren / decentraliseren trend in computers.

Van pre-cpu naar cpu zie ik meer als miniaturiseren en digitaliseren. Videokaarten en dergelijke worden gebruikt als oplossing voor wie niet genoeg heeft aan de standaard oplossing. Wel zie je vaak dat er eerst een standaard / bestaande cpu gebruikt wordt in combinatie met een chip die bijvoorbeeld alleen beveiliging of vingerafdrukken of zo verwerkt, die dan later geïntegreerd wordt, zoals bij Apple Silicon. Maar andersom zie je eigenlijk nooit.

Nee laten we het in de browsers stoppen want die staat tegenwoordig toch altijd open want de gewoon mensen/ burgers* heeft liever niet dat ze via gezichtsherkenning door bedrijven worden gevolgd. Dus laten het mogelijk dan maar in de browser inbouwen.

W3C noemt als mogelijke toepassingen object- of gezichtsherkenningen,

De EU wil het niet voor niets aan banden leggen
nieuws: Privacytoezichthouders pleiten voor Europees verbod op gezichtsherken...

Europese privacytoezichthouders willen dat er een algemeen verbod komt op camera's met gezichtsherkenning in de openbare ruimte. De European Data Protection Board schrijft ook dat er een verbod moet komen op 'AI-systemen' die onderscheid maken in etniciteit of geslacht.

* wij Tweakers zijn niet de gewone burger en hebben een andere kijk op techniek

[Reactie gewijzigd door xbeam op 23 juni 2021 13:28]

Wat snappen bedrijven niet aan wij gewoon mensen/ burgers* willen dit liever niet!

Afaik willen "we" (en dan bedoel ik dus echt de doorsnee mens/burger) het wel. Zaken als Faceunlock, Windows Hello etc worden nu ook gebruikt.

De EU wil het niet voor niet aan banden leggen

De EU wil het alleen weren uit de openbare ruimtes, dat betekent niet dat ze gezichtsherkenning totaal willen weren.

Afaik willen "we" (en dan bedoel ik dus echt de doorsnee mens/burger) het wel. Zaken als Faceunlock, Windows Hello etc worden nu ook gebruikt.

Dat is precies het probleem wanneer je ze vraagt wil de meeste mensen het niet. Maar wanneer deze of andere technieken toegepast worden weten of beseffen de meeste niet. Maar omdat mensen het onbewust wel gebruiken is geen excuus en betekent nog niet dat ze het ok vinden en willen.

De EU wil het alleen weren uit de openbare ruimtes, dat betekent niet dat ze gezichtsherkenning totaal willen weren.

Waar staan altijd de help je zelf computers met een webcam en browser? Of filmen mensen wat om hen heen gebeurt?
Kuch “Openbaren ruimtes “ kuch

nieuws: Facebook test sharingtool die gezichten scant in alle foto's op mobie...

[Reactie gewijzigd door xbeam op 23 juni 2021 13:52]

Dat ze het onbewust gebruiken betekent nog niet dat ze dan maar willen

Sorry, maar ik heb nog nooit iemand onbewust face-unlock zien gebruiken.....

Waar staan altijd de help je zelf computers met een webcam en browser?

En hoeveel procent is dat van de hele vloot computers? Simpelweg daar de camera's van verwijderen, het is echt niet nodig daarom alle camera's te verbieden.

Aangezien je niet alles leest (doe ik zelf vaak ook niet) zal ik het even quote

Photo Magic maakt gebruik van de gezichtsherkenningstechnieken die Facebook ook voor het taggen van foto's en zijn Moments-app gebruikt. Photo Magic scant de fotocollectie van een gebruiker en als gezichten van vrienden herkend worden, krijgt de gebruiker een notificatie met de suggestie de afbeelding via Messenger als een groepsthread te delen.

De webcam op zoon pc of telefoon hoeft dus niet constant aan te staan. En dat de gebruiker het prima vindt betekent nog niet dat de andere aanwijzing in de openbaren ruimte er mee akkoord gaan.
Daar zit het probleem. software herkent en analyseert en slaat meer mensen op dan alleen de gebruiker in die openbare ruimte.
https://www.ad.nl/tech/fa...tsherkenning-in~ac2881cf/

Willekeurige omstanders
Inmiddels is de gezichtsherkenningstechnologie van Facebook zodanig verbeterd dat ze nu bijna zo goed gezichten kan herkennen als mensenogen. Zo vindt Facebook niet alleen vrienden op groepsfoto's, maar ook willekeurige omstanders op vakantiefoto’s.

[Reactie gewijzigd door xbeam op 23 juni 2021 23:42]

Leuk, maar dus helemaal niet relevant aan dit artikel....

Het is 100% relevant omdat de Web Neural Network-api via de webcam meer mensen filmt en kan herkennen. Facebook zou hierdoor bijv de mogelijkheid krijgen om dit soort technieken wat ze nu met foto’s en de telefoon camera doen uit rollen naar de de browser en like buttons onder de berichten van andere websites.

[Reactie gewijzigd door xbeam op 23 juni 2021 14:40]

Facebook zou hierdoor bijv de mogelijkheid krijgen om dit soort technieken wat ze nu met foto’s en de telefoon camera doen uit rollen naar de de browser en like buttons onder de berichten van andere websites.

Right, dan geef je ze daar geen toestemming voor....
"ja, maar mensen kilikken toch wel op ok"..... dan is dat je probleem, niet de techniek.

Dit is het probleem malafide gebruik van dit soort mooie technieken
https://blog.malwarebytes...ns-feature-asking-abused/

The Notifications API lets a web page or app send notifications that are displayed outside the page at the system level; this lets web apps send information to a user even if the application is idle or in the background. This article looks at the basics of using this API in your own apps.

Dan denk je wie accepteert die pest notificaties nu?
Uhm, juist heel veel gewoon gebruikers omdat ze niet veder naar de site kunnen voordat ze op accepteren klikken en de gevolgen niet begrijpen en kunnen overzien.
https://www.bleepingcompu...your-are-not-a-robot-page

If you see a web site that states "Click allow to verify that you are not a robot" and then prompts you to allow notifications, do not click on the allow button. These sites are trying to trick you into subscribing to their browser notifications so that they can send notification spam directly to your desktop

Dus jou stelling is omdat mensen niet kunnen zwemmen en niet altijd begrijpen dat water gevaarlijk is. Kunnen we in heel Amsterdam de hekken/reling bij de grachten weg halen want het water zelf kan er niets aan doen dat er mensen invallen en verdrinken. Het probleem zijn de dronken toeristen

Zer0
@xbeam • 23 juni 2021 14:53
Facebook zou hierdoor bijv de mogelijkheid krijgen om dit soort technieken wat ze nu met foto’s en de telefoon camera doen uit rollen naar de de browser en like buttons onder de berichten van andere websites.
Right, dan geef je ze daar geen toestemming voor....
"ja, maar mensen kilikken toch wel op ok"..... dan is dat je probleem, niet de techniek.

[Reactie gewijzigd door xbeam op 23 juni 2021 18:01]

Dus jou stelling is omdat mensen niet kunnen zwemmen en niet altijd begrijpen dat water gevaarlijk is. Kunnen we in heel Amsterdam de hekken/reling bij de grachten weg halen want het water zelf kan er niets aan doen dat er mensen invallen en verdrinken.

Dat hekje is het feit dat je toestemming moet geven... wat jij wil is de grachten dempen.

Mensen die zonder nadenken toestemming geven zijn de dronken toeristen die over het hek klimmen.

[Reactie gewijzigd door Zer0 op 23 juni 2021 15:12]

[...]

Dat hekje is het feit dat je toestemming moet geven... wat jij wil is de grachten dempen.

Of anders bekeken jij vindt het prima wanneer ze een nieuwe gracht graven ( new api/feature) die mensen niet willen op plek een waarvan je zeker weet dat veel dronken jongeren op het hekje klimmen vallen en verdrinken. En dan heb nog een groep mensen die niet eigenlijk het hekje op willen klimmen maar gelokt worden omdat ze gevaren niet kunnen overzien. dat zijn de malifide websites en bedrijven zoals Facebook die er baat bij hebben als mensen op het hekje zitten er soms afvallen. Het gevolg is dat wij als samenleving de ziekenhuis kosten voor die gelukken betalen terwijl die bedrijven er dik verdienen?

Mijn stelling is omdat we bijna 100% dat er op deze drukke plek dronken mensen in gaan verdrinken en we de gracht tegen de zin van de bewoners gaan graven moeten we er gewoon niet aan beginnen.
Waarom iets bouwen wat niemand wil en gegarandeerd slachtoffers gaat opleven? Ik begrijp dat als ITer niet :-0
ik snap jou punt ook wel zeker wel en vind dit soort techniek ook super vet om mee te werken. Maar als ITers hebben we ook verantwoordelijkheid en moet je mensen tegen zichzelf beschermen. Als Marie Curie kon voorspellen/wist dat haar ontdekking zoveel een wapen met zoveel doden tot gevolg zou hebben dan had die steen gelijk weer in de revier gegooid.
https://nl.wikipedia.org/wiki/Marie_Curie

Maar zo heeft iedereen zijn eigen kijk op devrubberen tegels en de maatschappij. En dat houd het debat scherp

[Reactie gewijzigd door xbeam op 23 juni 2021 18:01]

die mensen niet willen

... en waar haal je vandaan dat mensen die niet willen? Het feit dat jij het niet wil betekend niet dat niemand het wil....

Dat is de democratie. Blijkbaar is er binnen Europa een gekozen meerderheid aan partijen die in opdracht van hun achterban pleiten voor een verbod in openbare ruimte. En dat verbod willen ze niet omdat mensen/burgers gezichtsherkenning leuk vinden? En dat verbod is nu niet iets wat ze voor de bedrijven of het grote geld doen want die helpen ze totaal niet mee.

[Reactie gewijzigd door xbeam op 23 juni 2021 23:29]

Waar heb je het over? Er is/komt helemaal geen verbod op gezichtsherkenning, er komt beleid om dit te weren uit openbare ruimtes...

En dat doe je met een algemeen (dus ook telefoon camera’s) verbod van dit soort camera’s in de openbare ruimte

Europese privacytoezichthouders willen dat er een algemeen verbod komt op camera's met gezichtsherkenning in de openbare ruimte

[Reactie gewijzigd door xbeam op 24 juni 2021 00:01]

Europese privacytoezichthouders willen dat er een algemeen verbod komt op camera's met gezichtsherkenning in de openbare ruimte

Dus geen algemeen verbod overal......

Ik vindt dat het mis moet gaan gewoon door laten gaan mensen kunnen hun verantwoordelijkheid niet continu op de overheid afschuiven of wel ik vindt het oké zolang er gevraagd wordt dat mag ook zijn mag deze site gebruik maken van een nn

"Willen" impliceert dat de persoon in kwestie minstens op de hoogte is van zowel mogelijke voor- als nadelen en niethoofdzakelijk omdat het makkelijk LIJKT zonder nadelen en mensen het daarom maar gebruiken.

Ter verduidelijking lijkt mij de tracking-pixels van fb een goed voorbeeld; mensen onbekend met het feit en de mogelijke nadelen boeit het (nog) niet, maar dat stelt niet dat ze bewust de keuze hebben gemaakt om het prima te vinden; dat wordt bij dat voorbeeld zelfs bewust gemede omdat het een transparante of onzichtbare pixel is in plaats van een "tracked-by-facebook"-symbool.

Ter verduidelijking lijkt mij de tracking-pixels van fb een goed voorbeeld;

Nee, dat is geen goed voorbeeld, want trackingpixels geven je geen bewuste keuze...

Dat is zeker wel een goed voorbeeld want de mensen die rond de plek/openbare ruimte waar iemand gezichtsherkenning gebruikt inbeeld komen krijgen ook geen keuze. Dat is wat ik je al een halve dag probeer uit te leggen. Naast het feit dat mensen die wel kiezen vaak door de website misleid of gedwongen worden in hun keuze.

[Reactie gewijzigd door xbeam op 24 juni 2021 01:12]

Dat is zeker wel een goed voorbeeld want de mensen die rond de plek/openbare ruimte waar iemand gezichtsherkenning gebruikt inbeeld komen krijgen ook geen keuze.

Je hebt potverdorie zelf gelinkt naar een artikel waarin staat dat de EU juist gezichtsherkenning wil weren uit openbare ruimtes......
Daar ligt de issue dus niet, het gaat om gebruik van oa gezichtsherkenning in prive omstandigheden.

hmm, al je advertenties herkennen mbv ML/AI

Ik vind dit zelf behoorlijk gaaf eerlijk gezegt. Als ik het goed lees kan deze API mijn GPU zijn neurale chip gebruiken voor deze berekeningen. Volgensmij best mooie ontwikkeling als deze api straks praat met alle chips van NVIDIA / Qualcom; dan heb je als developer het een stuk simpeler.

Dit soort data is natuurlijk nu heel lastig om te verzamelen als web applicatie bouwer dus ik snap dat privacy hier bij een groot struikelpunt kan zijn wanneer dit opeens super simpel wordt. Dat partijen deze data opslaan en kunnen misbruiken is vooral 'eng'.