'Apple negeert iOS-bug die andere url toont bij gescande qr-code'

Volgens onderzoeker Roman Müller heeft Apple tot nu toe geen patch uitgebracht voor een bug die hij naar eigen zeggen in december aan het bedrijf heeft gemeld. Door deze bug toont iOS een andere url bij een gescande qr-code dan waar de koppeling in werkelijkheid naartoe leidt.

Müller schrijft in een recente blogpost dat hij de melding op 23 december heeft gedaan, maar zegt niet op welke manier. Hij ontdekte dat het mogelijk is om een andere url te tonen in de notificatie die iOS 11 laat zien als een gebruiker zijn camera op een qr-code richt. In zijn voorbeeld toont de notificatie dat de koppeling naar Facebook leidt, terwijl deze in werkelijkheid verwijst naar zijn eigen site. Dit doet hij met een url die een speciale indeling heeft: https://xxx\@facebook.com:[e-mail]/.

Werking van de bug

De url-parser zou dit interpreteren als de gebruikersnaam 'xxx\' die naar poort 443 op Facebook.com gestuurd moet worden. Safari zou echter wellicht het hele deel van 'xxx\@facebook.com' als gebruikersnaam en 443 als het wachtwoord zien, aldus de onderzoeker. De bug is bijvoorbeeld te misbruiken doordat een gebruiker niet doorheeft dat hij naar een kwaadaardige site wordt gestuurd, bijvoorbeeld voor phishingdoeleinden.

Een aanvaller zou hetzelfde zonder de bug kunnen bereiken door bijvoorbeeld een url-shortenerlink in een qr-code op te nemen. Deze variant is wellicht iets minder effectief, doordat dan geen 'vertrouwde' url in de notificatie wordt getoond. Tweakers heeft de werking van de bug bevestigd op een iPhone 7 Plus met iOS 11.2.6.

Reacties (70)

[BugBoy]

Eigenlijk had deze URL helemaal niet geaccepteerd mogen worden. Het @ teken wordt in de hostname is normaal gesproken bedoeld om je username/wachtwoord mee te sturen voor HTTP basic authenticatie. Zo'n URL ziet er dan als volgt uit: https://user:[e-mail]. Daarmee ga je naar https://www.example.com en gaat er een authorization header mee, waarmee ingelogd wordt met de opgegeven credentials.

Het '@' teken is een gereserveerd karakter volgens RFC 3986 (bedoeld als separator voor user informatie). In deze RFC wordt er al gewaarschuwd voor dit probleem.

7.6. Semantic Attacks
Because the userinfo subcomponent is rarely used and appears before the host in the authority component, it can be used to construct a URI intended to mislead a human user by appearing to identify one (trusted) naming authority while actually identifying a different authority hidden behind the noise. For example ftp://cnn.example.com&sto...ws@10.0.0.1/top_story.htm might lead a human user to assume that the host is 'cnn.example.com', whereas it is actually '10.0.0.1'.

De camera applicatie is blijkbaar erg menselijk

[Reactie gewijzigd door BugBoy op 24 juli 2024 03:53]

[AmirIHz]

De url-parser zou dit interpreteren als de gebruikersnaam 'xxx\' die naar poort 443 op Facebook.com gestuurd moet worden. Safari zou echter wellicht het hele deel van 'xxx\@facebook.com' als gebruikersnaam en 443 als het wachtwoord zien, aldus de onderzoeker.

Volgens mij is dit helemaal geen bug, want achter een poortnummer in een URL hoort geen @, maar een / of niets. In dit geval is die @ dus gewoon het scheidingsteken tussen gebruikersnaam:wachtwoord en de hostname en is de eerst @ (die [b][/b] zou misschien zelfs wel als escapeteken kunnen gelden?) gewoon een karakter in de gebruikersnaam. : is een scheidingsteken tussen gebruikersnaam en wachtwoord.

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

https://en.wikipedia.org/wiki/URL

Als je de URL hier invoert, wordt hij ook als zodanig ontleed, maar het is waarschijnlijk geen officiële URL-parsing library: https://www.freeformatter...uery-string-splitter.html

Dit doet zich overigens ook gewoon in Safari op de Mac voor en heeft dus eigenlijk niks met die QR-code-scanner te maken, behalve dat je daarmee eventuele phishing gemakkelijker kunt verdoezelen. Maar goed, je stopt toch geen gevoelige gegevens zoals een persoonlijk wachtwoord in een QR-code? Volgens mij negeert Apple dit niet, maar heeft het gewoon weinig prioriteit heeft of omdat het works as designed is.

Firefox en Chrome (Mac) veranderen \@ in /@ en geven dan een verbindingsfoutmelding. Als je de [b][/b] voor @ weglaat (dus https://[e-mail]:[e-mail]/) dan maken Firefox en Chrome ook gewoon verbinding met https://infosec.rm-it.de/ en Firefox gebruikt dan [e-mail] als gebruikersnaam en 443 als wachtwoord! Firefox waarschuwt dan met de volgende melding die je moet bevestigen (ja of nee):

U gaat zich aanmelden bij de website ‘infosec.rm-it.de’ met de gebruikersnaam ‘xxx%40facebook%2Ecom’, maar de website vereist geen authenticatie. Dit kan een poging zijn om u te misleiden.

Is ‘infosec.rm-it.de’ de website die u wilt bezoeken?

Chrome gaat gewoon door naar https://infosec.rm-it.de/ zonder melding.

Wel een verdachte URL inderdaad...

[Reactie gewijzigd door AmirIHz op 24 juli 2024 03:53]

[Verwijderd]

Tweakers husselt het inderdaad een beetje door elkaar. Kort samengevat: de URL parser in Safari is prima, de URL parser in de QR scanner die onderdeel is van de iOS camera doet het fout.

[AmirIHz]

Je hebt gelijk. Ik zie nu ook dat het gaat om de melding van de camera/QR-scanner die niet klopt. Ik had het verkeerd gelezen. Dat is inderdaad een bug. Safari doet het dus wel goed.

[Relatief]

Lol wist niet eens dat de IOS camera een qr scanner had, thnx voor de tip xD

[kozue]

Volgens mij is dit helemaal geen bug, want...

Je spreekt jezelf later in je eigen post tegen, want de hostname is dus het laatste deel (infosec.rm-it.de), dus dat is wat weergeven had moeten worden in de prompt. Niet facebook.com.

Firefox en Chrome doen het goed: 443 is het wachtwoord en alles daarvoor is de username. Inclusief de \@, want een \ is geen url escape, en hoeft volgens mij ook niet escaped te worden. Dit is gewoon een slordige haastig geschreven hack om de hostname uit de url te halen. Als ze dezelfde code als safari hadden gebruikt was het goed gegaan, want volgens het artikel doet die het correct.

[AmirIHz]

Je hebt gelijk. Ik dacht dat de bug in Safari zou zitten volgens de onderzoeker, maar dat vond ik helemaal geen bug. Ik had de verkeerde melding (dus de URL-parsing van de Camera.app, die anders is dan zou moeten, maar wel uiteindelijk zoals het zou moeten door Safari wordt gedaan) over het hoofd gezien. Nogal een belangrijk detail, want dat is inderdaad een bug. Je wordt uiteindelijk naar de technisch juiste URL gestuurd, maar je denkt dat je naar facebook.com gaat.

<joke>Nu is de melding dat je naar facebook.com wordt gestuurd al een flinke waarschuwing op zich</joke>

[Reactie gewijzigd door AmirIHz op 24 juli 2024 03:53]

[Providentia]

Alhowel dit een bug is die (natuurlijk) gefixed moet worden, vraag ik mij wel oprecht af hoeveel mensen die gebruik maken van qr-codes gevoelig zijn voor fishing. Ik kan het mis hebben maar voor mijn gevoel maken mensen met weinig technische kennis nauwelijks danwel geen gebruik van qr-codes.

[Get!em]

Niet heel moeilijk hoor: vervang QR codes met stickers op de bordjes bij de monumenten in Amsterdam, Keukenhof en andere drukke bezienswaardigheden en je hebt een aardig publiek. Evenals plekken waar veel chinezen komen en die een chinese vertaling willen lezen: voeg gewwoon een sticker toe met qr die zogenaamd naar de chinese vertaling gaat.

[FreshMaker]

En een stap verder, vergang een eigen QRcode met die van de betaallink ( donatie )
Zeker welwillende bezoekers aan monumenten die 'modern' willen doneren kan je hier mee overhalen

[jeffhuys]

Bedankt voor de ideeën! Dit kan zonder bug ook..

[Fly-guy]

Je kan bij online aankopen via een QR code op je desktop, je mobiele ING app openen. Nu zit je bij het tonen van die QR code al in een Ideal omgeving, dus ik denk niet dat daar iets echt dit kan gaan, maar op zich is dat een mooie manier om deze bug te gebruiken om zo het geld maar iets anders over te sturen.

Daarnaast vermelden best veel advertenties en producten een QR code voor meer informatie.

[Verwijderd]

Voorraadbeheer gaat anders prima met qr

[jqv]

Alhowel dit een bug is die (natuurlijk) gefixed moet worden, vraag ik mij wel oprecht af hoeveel mensen die gebruik maken van qr-codes gevoelig zijn voor fishing. Ik kan het mis hebben maar voor mijn gevoel maken mensen met weinig technische kennis nauwelijks danwel geen gebruik van qr-codes.

Je vergist je een beetje.
Bij mij op school maken we regelmatig gebruik van QR-codes.
Dit maakt het studenten makkelijk om naar een website te kunnen gaan zonder alles in te hoeven tikken.
Dit is een onderdeel in de methode.
En deze methode wordt over heel veel MBO's gebruikt. Het gaat dan al snel om een duizenden studenten.

En de meesten zijn technisch niet best onderlegd.

In normale dagelijkse zaken, kan ik je opmerking wel steunen.

[Wilke]

Het levert alsnog wel een tamelijk verdacht uitziende URL op, lijkt mij.

[slicinghaunt]

nope, er komt in de notificatie "open 'facebook.com' in safari" te staan. kijk ook maar naar de afbeelding in dit artikel.

[Domih]

Als je de afbeelding bekijkt die bij het artikel staat dan zie je hoe de link er daadwerkelijk uitziet.

[tom.cx]

Inderdaad. Dit is de url: https://xxx\@tweakers.net:[e-mail]/

Het werkt nog super eenvoudig ook. Je zoekt op Google even naar een online QR code generator en klaar.

[SinergyX]

Maar ondervangt je browser dit niet gewoon door deze url nooit te kunnen verwerken? In jouw voorbeeld zou bv gros van de browsers naar xxx\ gaan, dus echt ver kom je niet.

[tom.cx]

Ik moet inderdaad de \ achter de xxx weghalen. Dan werkt hij gewoon in Safari op iOS. Google Chrome overigens ook op iOS.

[--Andre--]

Er mag toch enkel Apple's engine op een iOS device, dus elke browser is enkel een skin om Safari heen. Dus als de bug daar zit, heeft elke browser op een iOS device er last van.

[tom.cx]

Ik dacht dat het niet meer nodig was om de safari engine te gebruiken

[leuk_he]

Inderdaad, de browser laat anno 2018 toch altijd de URL zien waar hij op staat? aan de andere kant, de nieuws: Fraudehelpdesk laat phishingsite voor Tikkie-betaaldienst offline halen tikkie site geeft aan dat er altijd een paar mensen inlopen...

[R4gnax]

Inderdaad, de browser laat anno 2018 toch altijd de URL zien waar hij op staat?

De QR-code scanner in de iOS camera app alleen dus niet. En als de gebruiker dan argeloos een malware link bezoekt en het 'foute' adres in de adresbalk ziet staan, is het al te laat.

Dat is hier het hele probleem. En waar zowel jij als Wilke compleet naast kijken.

[supersnathan94]

Als je het foute adres in de adresbalk ziet staan is er nog steeds helemaal niets aan de hand aangezien je nog niet bent ingelogd. Daarbij komt ook nog eens dat er geen wachtwoorden voor uit je password store worden getrokken omdat het domein niet klopt.

Overigens is het volstrekt onlogisch dat bovenstaande url op deze manier wordt verwerkt. Het lijkt erop dat de qr dcanner een andere escaping gebruikt (backslash escaping) terwijl in URI’s gebruik moet worden gemaakt van “percent-enccoding” als het teken als Literal moet worden beschouwd. Bovenstaande URL is dus op alle mogelijke manieren fout aangezien er meerder separators staan (het @).

If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.

Apple voldoet met haar huidige implementatie dan ook niet aan RFC 3986 sectie 3.2.1:

Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible. Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).

Sectie 7.6 wijst dan weer specifiek naar een URI zoals die hierboven ook staat, met een userinfo subcomponent wat misleidend is:

ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_

Rare fout is dit dan ook. Ik heb het handmatig nog niet kunnen reproduceren met de gegeven url. Wel als je de backslash weglaat (wat normaal namelijk een valide delimiter is en dus wordt er verwezen naar XXX als domein).

[R4gnax]

Als je het foute adres in de adresbalk ziet staan is er nog steeds helemaal niets aan de hand aangezien je nog niet bent ingelogd. Daarbij komt ook nog eens dat er geen wachtwoorden voor uit je password store worden getrokken omdat het domein niet klopt.

Je mist het punt. Dit kan ook gebruikt worden om mensen naar speciaal geprepareerde malware-sites door te sturen. En dan is het wel degelijk 'te laat' zodra je browser die pagina al geopend heeft staan.

[leuk_he]

Ook dan is de echte bug de browser, die direct bijgewerkt moet worden als die gevoelig is voor malware.

[supersnathan94]

En wat voor sites zouden dat dan moeten zijn? Malware installeren op een niet jailbroken iPhone is simpelweg niet mogelijk. Installatie gaat niet werken. Ten eerste zul je voor externe (niet in app-store) apps een certificaat moeten installeren (wat al een no-go is) en ten tweede kunnen ze dan nog steeds niet zomaar de sandbox uit.

En dan is het wel degelijk 'te laat' zodra je browser die pagina al geopend heeft staan.

ik zie niet in hoe. Je hebt bij het installeren van het certificaat nog steeds heel veel opties. Installeren van een Applicatie via de browser kan niet worden geautomatiseerd op iOS en dus vergt dit userinput. Puur om dit soort dingen uberhaupt te kunnen voorkomen.

[R4gnax]

En wat voor sites zouden dat dan moeten zijn? Malware installeren op een niet jailbroken iPhone is simpelweg niet mogelijk.

Één 0-day is alles wat er nodig is om Safari te nekken. Maar blijf lekker blind vertrouwen op het feit dat Apple z'n security goed voor elkaar heeft, zou ik zeggen. We zullen zien hoe lang dat goed blijft gaan.Wist je dat in enkel het eerste kwartaal 2017 er al meer security exploits gepatched zijn in iOS dan in heel 2016? En dat die curve zich voortzet? Apple's platform is een lucratief doelwit voor criminelen geworden.

[Segafreak83]

Dan nog, niet iedereen gaat die url uitpluizen, zeker niet als je dagelijks bezig bent met QR-codes.

Slecht dat Apple daar niets mee doet, vind ik.

[Tarin]

Kijk het filmpje in de gelinkte blogpost even. De camerasoftware haalt een parser over de link voor fraaiere weergave heen en toont de verkeerde URL als doel ('Open "facebook.com" in Safari').

[t link]

Het hele punt is dat je die URL niet ziet voordat je hem daadwerkelijk opent. dit soort bugs zijn genoeg om aanvallen een stuk makkelijker te maken. niet alleen phishing, maar ook om gebruikers naar malafide sites te sturen die een exploit+payload droppen.

[Xessive]

Is het nu een problem binnen IOS, de camera app of Safari?

[.oisyn]

De camera-app, denk ik. Die doet zijn eigen url persing die niet klopt. Al zou het ook een iOS bug kunnen zijn die om bevestiging vraagt als een app vraagt een url te openen. Het zit iig niet in safari, die doet het goed

.edit: wacht, ik vlieg hier de bocht uit. Escaping in urls doe je met %, niet met \. Het lijkt me dus wél een bug in safari . De \ is een ongeldig karakter, dus de url is ongeldig.

Zie rfc 3986, sectie 3.2.1

[Reactie gewijzigd door .oisyn op 24 juli 2024 03:53]

[R4gnax]

De camera-app, denk ik. Die doet zijn eigen url persing die niet klopt. Al zou het ook een iOS bug kunnen zijn die om bevestiging vraagt als een app vraagt een url te openen. Het zit iig niet in safari, die doet het goed

.edit: wacht, ik vlieg hier de bocht uit. Escaping in urls doe je met %, niet met \. Het lijkt me dus wél een bug in safari . De \ is een ongeldig karakter, dus de url is ongeldig.

Zie rfc 3986, sectie 3.2.1

Klopt. De \ mag nergens in een URL zonder percent-encoding geaccepteerd worden.
Als Safari dat wel toe staat, dan is de URL parser daar idd. ook niet in orde.

Zal zeker niet de eerste keer zijn dat browsers URL parsers niet goed implementeren. En ook wel niet de laatste.

[Reactie gewijzigd door R4gnax op 24 juli 2024 03:53]

[TommyboyNL]

Naar mijn idee de camera app, die parsed de URL verkeerd en laat daardoor het verkeerde deel zien als domeinnaam.

[kaasboer09]

Ik kan me zo voorstellen dat de waslijst met security bugs aardig groot is, en dat dit niet echt top prioriteit krijgt. Verder natuurlijk goed dat deze bug openbaar gemaakt is.

[j1b2c3]

netjes na de 90 dagen wacht tijd prima daar kunnen bepaalde security bedrijven van leren!
maar idd het kan , maar wie gebruiken er QR codes? ik heb het de afgelopen 5 jaren misschien 5 keer een code gescand. en laatste jaren eigenlijk nooit

[DeFeCt]

Afgelopen week in Tallinn, Estland geweest en daar hangt het vol met QR codes. Het feit dat wij het hier in Nederland niet veel zien wil niet zeggen dat het elders niet gebruikt wordt.

[j1b2c3]

Ik was in Indonesië en daar worden ze eigenlijk ook niet gebruikt heel sporadisch zie je ze wel een keer. Maar op van die momenten dat je denkt nee niet echt handig

[Carlos0_0]

Op ING betalen na gebruik ik het echt nooit, en ik zie ook niemand meer gebruiken veder.

[Verwijderd]

Vandaag nog gebruikt met google authenticator.
Vorige week de digid inlogger geactiveerd met een QR code.

Worden vaak voor challenge-response doeleinden gebruikt.
Voor een URL eigenlijk nog nooit gebruikt.

[MrMonkE]

Best wel laakbaar.
Deze 'bug' lijkt me eenvoudig te fixen.

[Smurfuhrer]

Waar staat dat Apple deze bug 'negeert'? Roman zegt dat nergens volgens mij.

edit: aanhalingstekens

[Reactie gewijzigd door Smurfuhrer op 24 juli 2024 03:53]

[TommyboyNL]

Het feit dat deze bug al 90 dagen open staat lijkt mij voldoende bewijs voor die stelling. Het is niet alsof dit lastig te fiksen is voor een beginner in reguliere expressies.

[Smurfuhrer]

Het is geen stelling, het is een (niet bestaande) quote die toegeschreven wordt aan Ramon.

De fix komt waarschijnlijk gewoon met de volgende update.

[TommyboyNL]

Waarom moet dat dan zo lang duren? Doet Apple geen maandelijkse beveiligingsupdates zoals Samsung wel doet?

[Verwijderd]

Zal net als veel andere bedrijven gaan op basis van prioriteit en impact. Dit is nou niet zo’n groot beveiligingsrisico dat het met de grootste prioriteit moet worden opgepakt. Ja de camera app laat zien Facebook.com maar je komt uiteindelijk op het ware adres terecht, het is nou niet dat je dan gelijk hebt betaald of gehacked bent. Phishing is eigenlijk het meest voor de hand liggende screnario maar dan nog zal dit niet iedereen treffen, QR wordt in de praktijk door de regulier gebruiker weinig gebruikt. Als je sommige hier mag geloven lijkt het net alsof je direct al je gegevens kwijt bent.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 03:53]

[R4gnax]

Zal net als veel andere bedrijven aan op basis van prioriteit en impact. Dit is nou niet zo’n groot beveiligingsrisico dat het met de grootste prioriteit moet worden opgepakt. Ja de camera app laat zien Facebook.com maar je komt uiteindelijk op het ware adres terecht, het is nou niet dat je dan gelijk hebt betaald of gehacked bent. Phishing is eigenlijk het meest voor de hand liggende screnario maar dan nog zal dit niet iedereen treffen, QR wordt in de praktijk door de regulier gebruiker weinig gebruikt. Als je sommige hier mag geloven lijkt het net alsof je direct al je gegevens kwijt bent.

Reden dat je eerst een popup ter bevestiging krijgt, is om te voorkomen dat een gebruiker een schimmige site opent via QR.

Als gebruikers op deze manier alsnog op schimmige sites terecht komen die malware inzetten, dan kan het dus wel zo zijn dat ze gehacked zijn. Hangt er maar net vanaf of er een exploit gebruikt wordt waar Safari nog niet tegen beschermd is.

[BugBoy]

De laatste update van iOS was 11.2.6 en die is op 19-2 vrijgegeven. Toen was deze bug blijkbaar al wel bekend. Blijkbaar vindt Apple het niet belangrijk genoeg en heeft het nog niet opgelost.

[brammieman]

Off topic: Reguliere expressies? Moest het 2x lezen. Is dat NL voor regular expressions? Eerste keer dat ik iemand dat zie vertalen...

[TommyboyNL]

Jep. Ik vond het zo smerig staan met de Engelse naam, geen idee of dit een correcte vertaling is
Volgens Wikipedia overigens wel: https://nl.wikipedia.org/wiki/Reguliere_expressie.

[BugBoy]

Bij mijn opleiding (HIO Enschede, 1990-1995) werd ook gesproken over reguliere expressies. Is volgens mij een heel normale term. Maar misschien word ik oud. Of is de term CVE (centrale verwerkings eenheid) wellicht ook niet meer heel gangbaar?

[dev10]

Het is wel zo dat hoewel zo’n fix niet zo groot lijkt, je geen idee hebt wat er verder nog bij komt kijken. Software ontwikkelen en testen op die schaal zoals iOS ontwikkeld wordt is uitgebreider dan een simpele applicatie die door een paar honderd mensen gebruikt wordt.

[BugBoy]

Als de weergave en parsing van een URL in de camera applicatie hele grote gevolgen heeft buiten dat gedeelte, dan mag heel iOS wel eens op de schop. Ook voor Apple is dit een redelijk triviale fix die niet heel veel side-effects zal hebben (uitgaande dat ze de parsing hier zelf doen en niet vanuit het framework).

[BugBoy]

Als je urls gaat parsen d.m.v. reguliere expressies dan ben je niet goed bezig. Juist voor dit soort zaken moet je de standaard libraries in je framework gebruiken. Juist door het zelf bedenken van dit soort reguliere expressies ontstaan dit soort fouten. Gebruik in dit geval URLComponents die netjes RFC 3986 implementeert.

[Gamebuster]

iOS kan QR codes scannen met de camera app? TIL

[joepsel]

Ik heb me ook al altijd afgevraagd waarom er geen native barcode/QR-scanner in iOS zat. Nu blijkt ie er gewoon al in te zitten! Weet iemand vanaf welke iOS-versie al?

[Wraldpyk]

Dat is pas sinds iOS 11! https://www.macrumors.com...can-scan-qr-codes-ios-11/

[DennusB]

Ja, zeker. Gewoon in de camera app!

[HenkEisDS]

Apple gaat sowieso erg onduidelijk met URLs om. Als ik deze pagina bekijk in Safari zie ik alleen een slotje gevolgd door tweakers.net en is het voor mij niet zichtbaar dat "/nieuws/136673/apple-negeert-ios-bug-die-andere-url-toont-bij-gescande-qr-code.html" er nog achter komt. In Chrome is de hele URL ook niet leesbaar, maar wordt het op zijn minst duidelijk dat er nog een heel stuk achter het https://tweakers.net volgt. Misschien doet Apple dit om phishing moeilijker te maken, maar ik vind het niet prettig.

Ik werk veel met QR, 1D SSCC en 2D datamatrix codes en ben nog een andere onregelmatigheid tegengekomen in iOS. Ik heb een keer per ongeluk een spatie voor een URL verwerkt die als %20 oid in de QR was gekomen. URL:https://%20www.google.com. Hierdoor werkte de code niet in externe QR apps, maar iOS ging hier meer vergeeflijk mee om. Weet niet of ik dit moet zien als een bug of een feature, maar het kwam mij toen wel goed uit.

Ben echter nog steeds erg blij dat sinds iOS11 QR standaard in de camera app zit.

[vdws]

Safari -> Opties -> Gevanceerd -> "Toon Volledig Websiteadres" aanvinken lost dat voor je op.

[Carlos0_0]

Ken die optie niet vinden op mijn iPhone 8 plus, maar als ik op url klik komt volledige pagina in beeld.

[BugBoy]

Ik vermoed dat dit komt omdat je over het algemeen op de iPhone niet genoeg horizontale ruimte hebt om de volledige URL weer te geven. Alleen de hostname weergeven is dan duidelijker. Maar zoals je aangeeft kun je er op tikken en dan zie je het alsnog (en kun je ook bewegen door de URL als die niet past).

[HenkEisDS]

vdws heeft het waarschijnlijk over Safari op de Mac.

[vdws]

Ja, inderdaad. my bad...

[icegodd]

offtopic nieuws item :
Uh Oh! Unified Logs in High Sierra (10.13) Show Plaintext Password for APFS Encrypted External Volumes via Disk Utility.app
https://www.mac4n6.com/bl...lumes-via-disk-utilityapp

Oeps apple