Google gaat inloggen via embedded browsers blokkeren

Google gaat de mogelijkheid om in te loggen via embedded browsers blokkeren. Vanaf juni werken logins via embedded browser frameworks niet meer. Het bedrijf wil gebruikers zo beschermen tegen man-in-the-middleaanvallen.

Google kondigde de maatregelen vrijdag aan. Het bedrijf blokkeert in de toekomst loginmethodes via het Chromium Embedded Framework. Ontwikkelaars kunnen dat gebruiken om een embedded login voor Google-accounts te implementeren in hun applicaties. Gebruikers kunnen dan inloggen in de app zonder naar de browser te worden doorgestuurd. Applicaties als Steam of Feedly gebruiken die functie.

Volgens Google zijn gebruikers door zulke frameworks kwetsbaar voor man-in-the-middle-aanvallen. Het bedrijf kan namelijk niet verifiëren of het in zo'n geval om een legitieme inlog gaat of om een phishing-aanval. Met dat laatste kan een aanvaller inloggegevens ontfutselen, en zelfs tweestapsverificatiecodes verkrijgen als het slachtoffer gebruik maakt van sms.

Google is al langer bezig logins beter te beschermen. Sinds vorig jaar is het bijvoorbeeld verplicht JavaScript in te schakelen bij het inloggen, zodat het bedrijf beter toezicht kan houden op het inlogproces.

Google raadt ontwikkelaars aan om over te stappen naar OAuth-authenticatie in de browser als loginmethode. Daarmee kunnen gebruikers volgens Google ook gelijk de url van een loginpagina zien zodat ze zich beter kunnen beschermen tegen phishing. De maatregel gaat vanaf juni in.

Reacties (93)

JavaScript, is dat niet iets waar je juist van af wilt?
_{[edit] ik was in de war met Flash mensen, mijn excuses..}

[Reactie gewijzigd door Tranquility op 19 april 2019 13:44]

Je moet JavaScript in zijn geheel geen slechte naam geven. Het is inderdaad zo dat veel pagina's onnodig zwaar zijn door het gebruik van JavaScript functionaliteit om je te tracken, als je. Maar aan de andere kant zou een pagina wel heel statisch zijn zonder JS. Een plugin als NoScript blokkeert niet àlle JavaScript maar gebruikt een whitelist omdat als je alle JS zou blokkeren veel pagina's niet bruikbaar zijn.

Maar JS an sich is niet onveilig of zwaar.

JavaScript is net als Flash juist wel inherent onveilig, en blijft enkel bruikbaar door constant de JS engine en sandboxing in de browsers te blijven patchen voor nieuwe exploits. Fundamenteel beter is het pas als er helemaal geen client-side scripting is, dan ben je direct vrijwel alle attack vectors kwijt, plus secundaire problemen als geheime bitcoin miners, en zware scripts die accuduur slurpen.

Google is helaas een van de grote promoters van JS (en client side scripts in het algemeen), het is zonde dat ze geen pure HTML5 versie van Gmail hebben. Het kan wel, zo heeft Amazon een volledig functionele JS-vrije website.

Ik hoop nog altijd op een Web 3.0 waarbij er enkel nog CSS/HTML op de clients gerenderd wordt, en alle code serverside draait. Dan draait die code ook in de runtime daar waar hij het beste geverifieerd kan worden: bij degene die het geschreven heeft. Wil je per se dingen doen waarbij de code moet draaien op de client, schrijf dan lekker een native app, veel sneller/krachtiger ook. Werkelijk 99 procent van de websites die ik zie kunnen veiliger/sneller ofwel zonder JS, ofwel als app. Tweakers is er een van, bv.

[Reactie gewijzigd door Dreamvoid op 20 april 2019 23:53]

Deze websites zijn vaak zwaar door gigantische grote frameworks die front end developers gebruiken.

Die front-end developers denken alleen maar aan zichzelf en hun deadlines in plaats van een goed performant eindproduct op te leveren.

Nee ze gebruiken dan tooling die heel veel kilobytes met zich mee sleept zoals AngularJS, ReactJS en VueJS.

Deze frameworks zijn een soort alles in 1 pakketje. Terwijl developers ook gewoon uit die framework wereld kunnen stappen en performant bibliotheek blokjes bij elkaar kunnen rapen.

Vaak zitten developers ook vast aan hun framework omdat hun componenten zijn gemaakt specifiek voor dat type framework.

Er zijn gewoon andere betere oplossingen waar iets meer tijd en expertise nodig voor is... maar daar wil de front-end developer niet aan. Die wil alleen maar fanboy zijn van framework X en alleen die is heilig en krijgt dus omdat hij gevangen zit last van het https://nl.m.wikipedia.org/wiki/Stockholmsyndroom.

Met die frameworks kan je gewoon veel sneller een veel beter product maken dat in een library zit die zo populair is dat je er meerdere jaren support / workarounds voor kan verwachten.

Een site hoeft echt niet traag aan te voelen als je een van die frameworks gebruikt. Niet performant implementeren (omwille van tijdsdruk die je met spaghettilibraries zou moeten krijgen) heeft veel grotere gevolgen.

Mag ik je er op wijzen dat alle webpagina's zijn opgebouwd met behulp van JavaScript, waaronder dit reactieformulier. JavaScript biedt heel veel uitkomsten om websites soepeler te laten lopen.

De meeste webpagina's wellicht (en inderdaad het reactieformulier hier), maar zeker niet alle. Er zijn genoeg statische websites. Daarnaast als je je website maakt met AMP mag je bijvoorbeeld ook geen authored javascript gebruiken, maar alleen via iframes of AMP elementen.

Iframes ? Damn dat is zo 1990

Nee hoor, iframes zijn nog steeds zeer relevant. Je moet alleen wel goed bedenken waar je ze voor wil gebruiken. Een site opbouwen met (i)frames is inderdaad niet meer van deze tijd, maar er zijn nog genoeg andere toepassingen voor. Een voorbeeld, het insluiten van YouTube (en Vimeo en anderen) filmpjes werkt ook via een iframe. Gezien die zeer veel gebruikt worden, lijkt me dat zeker niet 'zo 1990'.

iframes worden nog heel veel gebruikt. Kijk maar eens naar trackingpixels vaak betreft het dan een 1pixel grote iframe. Frames, zonder de i- is heel erg jaren 90!

Frames zijn jaren 90. Iframes zijn toch wel een beetje de backbone van het interactieve web geweest tot de komst van jquery of worden nog steeds veel gebruikt samen met jquery

Er zijn ontzettend veel backoffice applicaties welke iframes gebruiken voor tabbed interfaces. tabbed interfaces verhogen de productiviteit omdat zoekschermen behouden blijven als je naar een detail page gaat. Bij een single document interface, overschrijf zou je het zoekscherm vervangen door een detail scherm. Ben je klaar, dan kom je terug bij het zoek scherm, maar bij veel applicaties ben je dan de state van de vorige zoekopdracht kwijt. Veel gebruikers openen dan expliciet zo'n detail scherm in een nieuwe browser tab.

Bij SPA applicaties (Angular, Vue, etc) heb je een router component welke deze taak op zich neemt. Echter is zijn veel backoffice applicaties het resultaat van meerdere jaren development en schakel je niet zomaar even over naar een andere interface.. Daarbij zolang men bezig met het herschrijven van de web interface, moeten alle GUI schermen dubbel beheerd worden. De oude methode en de nieuwe methode, want mixins van oude en nieuwe presentatie technieken staan garant voor problemen.

Wat dacht je van embedded videos, google maps kaartjes, etc.? Dat is veelal toch gewoon met een iframe gedaan.

"Alle webpaginas" is natuurlijk niet waar. Zelfs van alle webpaginas die javascript gebruiken, werkt een groot deel nog gewoon als javascript uitgeschakeld staat. (Mochten de developers daar aan gedacht hebben natuurlijk)

Correct. Maar javascript is niet perse altijd nodig. Er zijn genoeg andere opties. Het is dan minder flashy maar het werkt wel.

Mensen verwarren JavaScript vaak met Java en dat laatste staat bekend als onveilig, ouderwets etc.

Zoals @Ionicawa zegt zijn de applets het onveilige deel van Java, maar die worden nauwelijks nog ondersteund/gebruikt.

Java is natuurlijk wel heel oud (komt uit 1996), maar er worden nog steeds met regelmaat nieuwe versies uitgebracht. Daardoor is het zeker niet ouderwets! Sterker nog Java is één van de meest gebruikte programmeertalen!

Weet ik maar heel veel mensen verwaren javascript dus met die applets en brakke browserplugins.

Zo heb ik al lang niemand meer tegengekomen..

Client-side Java applets in browsers zijn onveilig en ouderwets.

Java an sich is niet per definitie onveilig of ouderwets.

Onzin niemand doet dat. Dat zeggen alleen mensen tegen andere mensen. De mensen waar je over praat bestaan niet.
Je kan talen toch allemaal opdelen. Elke programmeur weet toch het verschil tussen systeemtaal, bytecodetaal, scriptingtaal. Etc. OOP/Imperatief/Functioneel etc?
Je kan talen in hokjes douwen zonder naar de syntax te kijken. Elke taal heeft zijn sterke en zwakke punten.

Zo kies je toch een taal uit voordat je gaat programmeren? Syntax is bijzaak.

Klopt helemaal, ik was in de war met Flash, wat hetgeen is wat je niet meer wilt...

Waarom dit reactieformulier niet gewoon in HTML/CSS zonder JS wordt geschreven, is me nooit echt duidelijk geworden. Zijn we dan allemaal zo bang voor een page reload?

Waarom zou je de hele pagina opnieuw laden met een kleine verandering terwijl je met een async call ook met een lichte query een divje kan updaten?

Omdat je dan op de client geen JS engine hoeft te draaien, met alle security implicaties van dien.

Als je van saaie statische pagina's houd wel ja.

Mwah je kunt al die niet saaie dingen veelal gewoon in CSS doen. Animaties via Javascript is echt een no go. Krijg je weer van die JQuery apps die 5mb over de lijn trekken om een stukje tekst te laten zien.

Nee javascript is ontzettend handig voor data visualisatie en DOM manipulatie en met frameworks als react en angular kan het ook ontzettend snel en veilig gebruikt worden. Het enige grote issue met frontend development is dat er zoveel duizenden libraries zijn die door jan en alleman gebruikt worden dat het onbegonnen werk is om te checken of er geen shenenigans worden uitgevoerd en dat de lib die jij gebruikt ook weer tig dependencies nodig heeft.

Wat dacht je van een registratie formulier dat checkt of je een geldig telefoonnummer hebt ingevoerd en dan direct een melding weergeeft? Of dat er meteen gecheckt wordt of de gekozen username nog niet bezet is? Zonder javascript zul je het formulier moeten submitten, serverside dit alles moeten controleren, dan weer een pagina moeten terugsturen. Dan ben je constant de pagina aan het herladen puur om te zien of jouw ingevulde gegevens geldig zijn.

Er zijn ongelofelijk veel dingen die er met JavaScript worden gedaan die het web zoveel gebruiksvriendelijker maken. Je kunt met CSS wel wat animaties maken, maar je kunt geen client-side logica uitvoeren in HTML en CSS, dan is er altijd een page refresh nodig om nieuwe zaken te tonen.

Wat dacht je van een registratie formulier dat checkt of je een geldig telefoonnummer hebt ingevoerd en dan direct een melding weergeeft? Of dat er meteen gecheckt wordt of de gekozen username nog niet bezet is? Zonder javascript zul je het formulier moeten submitten, serverside dit alles moeten controleren, dan weer een pagina moeten terugsturen. Dan ben je constant de pagina aan het herladen puur om te zien of jouw ingevulde gegevens geldig zijn.

En is dat per definitie een slecht ding? In feite doe je met javascript natuurlijk hetzelfde maar dan doe je het als een los request. Dat werkt handiger maar het is nog steeds een apart request dat je naar de server stuurt. (of ga je eerst alle gebruikersnamen ophalen in een javascript variabel zetten en dan kijken met je validator of dat het e-mail adres dat is opgegeven daar tussen zit... )

Dat klopt, maar of het een fijne user experience is tegenwoordig? En laten we eerlijk zijn, zonder JavaScript was het web nooit zo ver ontwikkeld als dat het nu is. Denk aan dingen als online versies van Office en andere web based applicaties. Die zouden nooit mogelijk zijn zonder JavaScript. HTML en CSS is gewoon erg beperkt qua interactie.

Ja je kunt met CSS animaties maken, en je kunt een menuutje laten uitklappen bij een hover. Maar met enkel HTML en CSS zul je bijvoorbeeld nooit een link kunnen maken welke na een enkele klik een menu opent. Denk aan een "lees meer" knop of iets dergelijks.

Of wat dacht je van toegankelijkheids opties op regeringswebsites, zoals het groter en kleiner kunnen maken van tekst on the fly, of het aanbieden van een widget die tekst voorleest of vertaald. Dit zijn dan ook maar enkele voorbeelden van de duizenden scenarios die onmogelijk zouden zijn zonder JavaScript.

[Reactie gewijzigd door s1h4d0w op 19 april 2019 15:30]

Maar met enkel HTML en CSS zul je bijvoorbeeld nooit een link kunnen maken welke na een enkele klik een menu opent. Denk aan een "lees meer" knop of iets dergelijks.

Het is mogelijk om creatief te zijn met css. Je kan bijvoorbeeld een label gebruiken om een (onzichtbare) checkbox aan te vinken. Het ::checked zijn kan vervolgens resulteren in het zichtbaar worden van een divje waardoor je het effect krijgt dat jij omschrijft. Semantisch? Nee. Functioneel? Ja.

Klopt, maar dat kan in de achtergrond waardoor je de flow van de gebruiker niet onderbreekt.

Voor de ux is dat een slecht ding ja, maar ook voor je data. Met javascript kun je immers op de achtergrond een losse request doen zonder de hele pagina opnieuw te laden.

Euhm dat kan gewoon met HTML tegenwoordig? Heb je helemaal nul javascript voor nodig. Formulier wordt dan ook niet gesubmit en is allemaal client side.

Met alleen html kun je geen data naar de server sturen. Dat doe je met php, maar voor een betere gebruikerservaring doe je dat via javascript (ajax), zodat je op de huidige pagina blijft (en wat minder data verbruikt).

Maakt niet uit. De controller logica die aan je submit knop hangt wordt door je browser geblocked als je form validatie niet slaagt. Browsers hebben daar ingebouwde logica voor. Je clickhandler wordt dan simpelweg niet eens aangeroepen.

Wat dacht je van een registratie formulier dat checkt of je een geldig telefoonnummer hebt ingevoerd en dan direct een melding weergeeft? Of dat er meteen gecheckt wordt of de gekozen username nog niet bezet is? Zonder javascript zul je het formulier moeten submitten, serverside dit alles moeten controleren, dan weer een pagina moeten terugsturen. Dan ben je constant de pagina aan het herladen puur om te zien of jouw ingevulde gegevens geldig zijn.

Tegenwoordig kan je dat via de attributen van je input-element zelf afdwingen: https://developer.mozilla...eb/HTML/Element/input/tel

Een van de weinige nieuwigheden van HTML5 die in waardeer.

[Reactie gewijzigd door RoestVrijStaal op 19 april 2019 19:13]

Zonder javascript zul je het formulier moeten submitten, serverside dit alles moeten controleren, dan weer een pagina moeten terugsturen.

Dat is ook hoe je het zou moeten doen uit security oogpunt, dat soort code hoort niet op de client te draaien. Je weet nooit wat er op de client gebeurt, er kan van alles geinjecteerd worden in die browser zonder dat de gebruiker het weet. Draai het serverside, en degene die de code schrijft, die voert m ook uit.

[Reactie gewijzigd door Dreamvoid op 20 april 2019 23:56]

Dat hoeft ook niet, je kunt met ajax (javascript) asynchroon een ander script serverside het laten controleren en dan een boolean terug sturen of bijv. een username wel/niet nog beschikbaar is. De code die dan clientside wordt uitgevoerd is enkel een “op keydown een request maken naar check.php met de waarde van input veld x, dan melding tonen als return true of false is”. Heel simpel dus en maakt het allemaal wat fijner, maar zulke zaken kun je niet doen zonder javascript.

Maar wat is er mis mee om dit sowieso zonder JS te doen? Buiten die ene page reload?

Ik bedoel, niks mis met JavaScript op zichzelf, je kan er serverside hele leuke dingen mee doen, maar waarom je gebruiker met alle risico’s van een runtime opzadelen waar willekeurige ongeverifieerde code van het web in draait die god weet wat doet?

[Reactie gewijzigd door Dreamvoid op 21 april 2019 00:10]

Inderdaad, JavaScript is control logic, geen view logic. Animaties/vormgeving hoort in CSS thuis, informatiestructuren in HTML. En de "dozenschuiflogica" in JS.

CSS is enorm beperkt wat betreft dynamische animaties of het gebruik van timelines, het is daarmee in de praktijk slechts geschikt voor simpele transities. Libraries gespitst op animatie zitten ook nog tjokvol optimalisaties zoals flip technieken, het combineren/optimaliseren van geanimeerde properties, scheduling, en ga zo maar door.

CSS is ontzettend krachtig qua animaties/timelines etc. Het kan vast dat er dingen zijn die je niet kan maar zelf doe ik het dan liever gewoon niet.

Als het wel nodig is hecht ik de voorkeur aan het opsplitsen van des scheduling en de daadwerkelijke animatie. JS update dan puur class definitie CSS haakt daar in met een animatie.

Ik zag laatst nog iemand die een complete 3D game in puur CSS had gemaakt. Ik denk niet dat er iets is wat CSS niet kan... Of je het moet willen is een andere vraag natuurlijk, kan me best voorstellen dat een hoop dingen simpeler worden als je er wat JS bij gebruikt.

Helaas is 'puur css' daar een beetje een misnomer, die demo gebruikt namelijk ook HTML en ja, ook Javascript.

Zelfde als Ed zegt zo te zien, animatie in 'pure' CSS en de control logic e.d. zijn in JS.

Inderdaad. Je kunt wel animaties maken met CSS maar die kun je niet uitvoeren buiten op een hover oid. Je kunt niet zeggen “als gebruiker de D toets indrukt moet het poppetje animeren en naar rechts bewegen”. Daarom is javascript een must voor een beetje interactief web.

What about canvas...

De uitzondering die de regel bevestigd.

Dat doe je ook met javascript toch?
-edit- foutje

[Reactie gewijzigd door mjz2cool op 20 april 2019 09:34]

Ja, het is een api die via javascript kan worden aangeroepen.

Klopt, wil je de gebruiker iets laten uitvoeren op het canvas dmv bijvoorbeeld het toetsenbord dan heb je daar toch javascript voor nodig.

Zeker geen ontwikkelaar? Want CSS en JavaScript worden vaak gecombineerd.
CSS bied hardware matige transitions. Maar geen control logic. JavaScript is dus vaak gewoon nodig om animaties te initiëren. Een goede site heeft zelfs verschillende fallback scenarios waarbij CSS3 , canvas en per pixel animation allemaal ondersteund worden voor verschillende devices/browsers.

Uiteraard worden ze vaak gecombineerd. Dat js wordt gebruikt voor initiatie van animaties is zeker waar, maar dingen als hover en tooltips wordt allemaal standaard al afgehandeld. Je hebt geen js nodig voor dergelijke transitions.

Javascript is daarentegen proma geschikt voor DOM manipulatie waarmee je effctief css animaties kunt initiëren. Betekent niet dat je js nodig hebt voor de animatie zelf.
Ja bij de overige complexere dingen ws wel, maar dan hebben we het dus al over visualisaties van graphs en bijvoorbeeld image carousels. Geen enkel probleem om daar javascript voor te gebruiken. Again dit gaat om data visualisatie.

En die fallback scenarios is zeker waar. Maar de reden is vaak support voor oudere browsers.

Mwah je kunt al die niet saaie dingen veelal gewoon in CSS doen

Zonder logic control? Kom aan, je weet wel beter, als je complexe dingen wilt kan je niet om dat soort dingen heen.

Ik heb het toch nergens over complexe dingen? alleen over niet saai. Er kan echt heel veel al met CSS only.

Waarom wil je animatie met CSS doen. CSS is een stylesheet. Net zoals HTML statisch is.
Ik mag hopen dat je als developer zoiets geleerd hebt als "seperation of concern".

Dingen moeten dingen doen waarbij ze horen. Officieel vind ik persoonlijk animaties niet in CSS thuishoren omdat de rest van de applicatie niet de state van deze animatie kan inzien. Ook kan CSS animaties soms rare dingen doen waar je in je applicatie geen rekening mee had gehouden vanwege je javascript!!!

Ik raad je aan eens je geest te verruimen naar artikelen zoals deze:
https://css-tricks.com/my...animations-vs-javascript/

Animaties horen thuis in Javascript. Niet in CSS.

Misschien moeten we de semantiek van animaties eens bespreken want ik denk dat we daar langs elkaar heen praten. Met animaties bedoel ik in dit geval dingen als hover effecten en simpele grafische transities of arceringen. Iets als een button press effect of loading spinner bijvoorbeeld. Voor dergelijk spul heb je helemaal geen javascript nodig voor het effect zelf.

Animaties via Javascript als je die goed implementeerd met WAAPI zijn even performant als CSS animaties. Ze maken gebruik van dezelfde render methodes.

Je kan WAAPI + Lit-HTML + SVG veel gafere dingen doen die even performant zijn dan CSS animaties.

Klopt. Ik denk zelf dat het ook een stuk makkelijker is dan CSS doordat je daar vaak met verschillende elementen moet werken voor verschillende browsers om hetzelfde te kunnen doen.

Het enige nadeel van Web Animations API is de support. Die is helaas nog niet on par met hoe CSS nu is geïmplementeerd. Voor edge is het bijvoorbeeld nog maar de vraag of er wat mee gedaan gaat worden.

Eens. CSS animaties was er eerder. Hoewel beperkter, beter ondersteund door verschillende browsers. Technisch gezien ben ik voorstander voor Animaties in JS. Echter voor ondersteuning met name met simpele Animaties voor een breed publiek is CSS animaties dan weer praktischer. Ik betrap mezelf altijd erop dat de wereld niet perfect is en ben een beetje een purist. Terwijl dat niet altijd goed reflecteerd in de praktijk. Mijn excuus.

Haha. No problem man. Ik ken het probleem. Iets met immutable objects, builder patronen, thread safety en state enzo.

Separation of concerns is een mooi idee, maar in sommige gevallen zorgt het er voor dat het niet per se makkelijker wordt. Als je je animaties af kunt met CSS, waarom zou je dan extra code willen importeren (want dat is vaak wat er dan gebeurd) om hetzelfde in javascript te kunnen doen op de plek waar het idealiter hoort. Als het geen performance gain oplevert is de kans alleen maar groter dat de beheerbaarheid er op achteruit gaat.

Het bekende voorbeeld van de stackoverflow: ik wil graag X kunnen doen zonder JQuery.

Oke hier zijn 6 regels vanilla JS waar je dat mee kunt doen

Ja maar met JQuery kan het op 1 regel dus dat is beter

... 🤦🏾‍♂️

En dan over op .... ?

Volgens mij ben je in de war met Flash...

Waarschijnlijk met Java

Ha. Ik denk het niet hoor. Java is nog steeds een van de belangrijkste talen ter wereld. Daar wil je niet zomaar vanaf. Dat kan ook niet zomaar ff gelukkig.

Op t web is het echter een ander verhaal. De java applets van vroeger moet je niet meer aan willen beginnen.

Klopt helemaal...

JavaScript is juist erg opkomend de laatste jaren. Vooral met de implementatie op servers, sinds het met NodeJS op de back-end kan draaien.

Ik ben dan ook erg benieuwd of je zelf in deze wereld zit, aangezien ik, als developer, precies het omgekeerde zie.

NodeJS op back-end vind ik persoonlijk erg tricky. Je hebt (oa) geen enkele typesafety namelijk. Ik zou niet zomaar belangrijke infrastructuur op een scripting taal als JavaScript gaan draaien.

Natuurlijk wil je er vanaf, maar tot er iets beters tot wereldstandaard wordt zitten we ermee opgescheept.

Ja daar willdn goede developers van af ja. Typescript zou een goede vervanger zijn.

Puur uit nieuwsgierigheid en interesse: is er ook bekend of er eventuele gevolgen voor Cordova/Phonegap is? Dus voor apps die specifiek gebruik maken van een webview?

In mijn ogen is dat éénzelfde situatie namelijk: het embed de functionaliteit van een browser in een app.

Een webview gebruikt de native browser van het OS; dat zou goed moeten gaan.

Puur uit nieuwsgierigheid en interesse: is er ook bekend of er eventuele gevolgen voor Cordova/Phonegap is? Dus voor apps die specifiek gebruik maken van een webview?

Naar mijn weten kan dat al niet sinds 2016: https://developers.google...tions-in-native-apps.html

In React Native webview's is het mij in ieder geval niet gelukt om in te loggen via een Google login pagina. Als dat wel in Cordova/Phonegap nog kan, is dat wel enigzins vreemd te noemen.

edit: zelf geen ervaring met Cordova/Phonegap trouwens.

[Reactie gewijzigd door JorzoR op 19 april 2019 11:27]

Dit is zonder twijfel een goede beslissing, want de controle van de omliggende applicatie op zo'n embedded browser is natuurlijk wel een probleem. Echter vind ik dit wel enorm kort dag, een week of 5/6.
Is er hierover eerder een advies uitgegaan, of zijn partijen die dit actief gebruiken al eerder op de hoogte gestelt?

Beetje vaag dat Google, de hoofd contributor van het Chromium framework en tevens de basis voor Google Chrome's eigen browser, zo weinig vertrouwen heeft in z'n eigen sourcecode dat ze dit er uit slopen.

Ook grappig dat ze het verplicht stellen van Javascript, want dat helpt hun op welke manier? Ons is altijd geleerd dat Javascript never ooit te vertrouwen is _juist_ omdat het op de lokale machine draait en te bewerken is.

OAuth is wel goed, maar dat kan ook prima via embedded browsers, 2FA zou nog beter zijn.

Beetje vaag dat Google, de hoofd contributor van het Chromium framework en tevens de basis voor Google Chrome's eigen browser, zo weinig vertrouwen heeft in z'n eigen sourcecode dat ze dit er uit slopen.

Ze vertrouwen hun eigen code in hun eigen handen. De code in andermans handen, met andermans wijzigingen vertrouwen ze niet. Dat lijkt me geen rare gedachte. Een webframe veilig implementeren is heel erg lastig, en het lijkt me naïef om aan te nemen dat een applicatie het juist doet. Dit geldt vooral voor applicaties waarbij dat webframe bijzaak is dat alleen tijdens de authenticatie wordt gebruikt (en dus nauwelijks wordt onderhouden).

Ook grappig dat ze het verplicht stellen van Javascript, want dat helpt hun op welke manier? Ons is altijd geleerd dat Javascript never ooit te vertrouwen is _juist_ omdat het op de lokale machine draait en te bewerken is.

Dat is te simpel. Javascript is inderdaad niet zonder meer te vertrouwen, maar google gebruikt JS niet in een vacuum. In combinatie met andere technieken is het zeker een nuttige aanvulling om vertrouwen te vergroten. Indien je JS oplossing goed geïmplementeerd is, maakt het fraude veel lastiger. Een crimineel zal veel tijd moeten spenderen om de JS op de juiste manier aan te passen. Als je je JS oplossingen met de juiste interval roteert, zijn criminelen voltijd bezig om hun aanval aan te passen, en houden ze geen tijd over om de aanval uit te voeren.

OAuth is wel goed, maar dat kan ook prima via embedded browsers, 2FA zou nog beter zijn.

OAuth is een manier om een applicatie te authenticeren, 2FA is een methode om een gebruiker te indentificeren. Ze zijn geen alternatief voor elkaar: je kunt OAuth niet door 2FA vervangen, en je kunt 2FA niet vervangen door OAuth. Bij het autoriseren (dat is iets anders dan authenticeren) van OAuth zou je wel 2FA kunnen gebruiken om de gebruiken te autoriseren.

[qoute]
Ze vertrouwen hun eigen code in hun eigen handen. De code in andermans handen, met andermans wijzigingen vertrouwen ze niet.
[/quote]

Als eigenaar van het project hebben ze het volledig zelf in de handen, ze kunnen zelf de merge requests weigeren mocht het ze niet aan staan, dus die andermans wijzigingen vertrouwen is een kul argument, simpelweg omdat Google Chrome op precies hetzelfde framework draait.

Dat is te simpel. Javascript is inderdaad niet zonder meer te vertrouwen, maar google gebruikt JS niet in een vacuum.

Ik hou van simpel. Alles zou in theorie prima zonder JS moeten kunnen draaien, maar vergt gewoon veel meer handelingen aan de gebruiker z'n kant, iets wat blijkbaar ten allen tijde voorkomen moet worden. Overigens ben ik heel erg Pro JS, maar om nu te stellen dat het daardoor veiliger wordt vind ik een non-argument. Het maakt het allemaal wel een stuk makkelijker voor de gebruiker, maar niet veiliger, alle source code is vrijelijk beschikbaar.

Ze zijn geen alternatief voor elkaar: je kunt OAuth niet door 2FA vervangen, en je kunt 2FA niet vervangen door OAuth.

Volgens mij heb ik dat ook nergens gezegd? Afijn, ik snap wat je bedoelt te zeggen

Als eigenaar van het project hebben ze het volledig zelf in de handen, ze kunnen zelf de merge requests weigeren mocht het ze niet aan staan, dus die andermans wijzigingen vertrouwen is een kul argument, simpelweg omdat Google Chrome op precies hetzelfde framework draait.

Maar dan ga je er van uit dat de gebruikers van de source-code ook exact die code compileren, en geen eigen wijzigingen aanbrengen. En juist dat is niet zomaar te controleren.

Doorgaans is het verschil tussen een site met JS en dezelfde functionaliteit zonder JS enkel een page reload - worden gebruikers daar nou werkelijk zo door verward? JS is zo’n enorm brede aanvalsvector, om dat de eisen van een gebruiker in ruil voor enkel wat vermeden reloads, dat is in mijn ogen gewoon onverantwoordelijk.

Helaas krijg je met JS hetzelfde als met Flash, als in: “de gebruiker heeft het toch draaien, want iedereen anders maakt zijn sites ermee, dus doe ik het ook maar”. We zijn nu vijftien jaar verder, en geen steek opgeschoten. Elke generatie webdevelopers maakt weer dezelfde fouten. Wie herinnert zich nog dat iedereen op Tweakers riep dat irritante banners en overlays met audio/video tot het verleden zouden behoren als we Flash maar dumpten? Surprise, die kon je ook in JS bouwen.

[Reactie gewijzigd door Dreamvoid op 21 april 2019 00:05]

Juni.. kort dag als je weinig capaciteit hebt. (elk IT bedrijf in nederland zo ongeveer)
Dat wordt aanpoten voor sommige bedrijven.

Tip: die mensen die embedded systems wel willen blijven gebruiken kunnen waarschijnlijk wel een cookie van hun normale systemen halen om het inloggen gewoon te omzeilen. (needs testing)

Het bedrijf wil gebruikers zo beschermen tegen man-in-the-middleaanvallen.

Oh, wat nobel! En toevallig ook zorgen dat google services niet meer gebruikt kunnen worden vanuit niet-google apps? Of is dat slechts bijzaak?

Eindelijk niet meer via een wazig paneeltje meer inloggen met nVidia Geforce Experience, ik stoorde me er eerlijk gezegd al een tijdje aan. Eigenlijk zou de applicatie een callback van een (zelf gekozen) browser moeten krijgen. Dit kan wat mij betreft niet snel genoeg ingevoerd worden.

Ik snap wat 'embedded browsers' zijn, maar ik weet zo snel niet welke veelgebruikte praktijkvoorbeelden hier momenteel bij horen. Moet ik bijvoorbeeld denken aan Electron?

Edit: Ik heb zelf wat gezocht, maar ik kon lastig vinden of 'Chromium Embedded Framework' nou door Electron wordt gebruikt, of dat het echt een alternatieve techniek is. Op Atom.io zegt iemand dat Electron ooit wel CEF gebruikte, maar nu is geswitcht naar Chromium’s APIs:

The Chromium Embedded Framework (CEF) is a project that turns Chromium into a library, and provides stable APIs based on Chromium’s codebase. Very early versions of Atom editor and NW.js used CEF.

To maintain a stable API, CEF hides all the details of Chromium and wraps Chromium’s APIs with its own interface. So when we needed to access underlying Chromium APIs, like integrating Node.js into web pages, the advantages of CEF became blockers.

So in the end both Electron and NW.js switched to using Chromium’s APIs directly.

[Reactie gewijzigd door StephanVierkant op 19 april 2019 13:43]

In Android heb je bijv. WebView, dit is een soort barebones browser window dat je in jouw app kunt verwerken om webpagina's te tonen. Ik heb bijvoorbeeld wel eens Android "apps" gemaakt die gewoon een WebView zijn met de mobiele website er in. Een soort verkapte webapp dus, maar mensen wilden graag een app en vonden dit na downloaden helemaal prima. Deze wijziging van Google gaat dit soort apps dus verbieden wanneer er ingelogd moet worden. Dan moeten mensen vanuit de app naar de browser gestuurd worden om in te loggen, en dan moeten ze weer terug naar de app.

De reden waarom dit gebeurd is omdat je zo vaak niet de url en het certificaat van het domein kunt zien. Op die manier kan een app dus gemakkelijk een nagemaakte inlog pagina van bijv. Google laten zien, zonder dat de eindgebruiker kan controleren of deze echt is.

Maar hoe leg je dan de koppeling tussen de inlog van de browser en je app......

Spotify gebruikt CEF, Electron is idd een eigen laag op Chromium APIs.

Electron draait naar mijn weten op een Chromium variant. Zou dus gewoon moeten blijven werken.

QT gebruikt bijvoorbeeld https://wiki.qt.io/QtWebEngine

Deze wordt waarschijnlijk gebruikt als embedded browser in de Tesla auto's en veel meer waar QT framework wordt gebruikt.

Embedded browsers zijn overal!! Ook bijna elke Kiosk achtige systemen gebruiken dat. In ziekenhuizen, macdonalds, gamma etc.

Wat een bs, nu moet je voor ieder wissewasje dus een normale browser gebruiken. Maakt het minder gebruiksvriendelijk. Dan zullen google's applicaties makkelijker in gebruik zijn en mensen die meer gebruiken. Dat is de enige goede reden die ik kan verzinnen.

Want phishing kan ook plaats vinden in de normale browser.

[Reactie gewijzigd door PlowKing op 19 april 2019 11:30]

De MITM aanvallen lijken inderdaad niet de reden voor deze wijziging, anders hadden ze wel met een deftige oplossing gekomen.

Je bedoelt die "embedded browsers" die Google zelf en allerhande andere chat- en nieuws-apps iedereen door de strot douwen tegenwoordig? Of gaat het hier om wat anders? Ik heb het over die dingen waar als je in Telegram bijvoorbeeld een bericht aankrijgt met een link, die linkt niet opent in de "echte" Chrome, maar in een browser binnen de app zelf.