Skip to main content
Naar NS.nl
Ik heb zojuist een aantal keer geprobeerd om mijn e-ticket te printen. het is een pdf, maar er is iets raars aan de hand... Als ik op print druk komt er een leeg blaadje uit de printer... keer op keer... Morgen ga ik weg en ik heb dit ticket dus nodig.... aargh.... Wie kan me helpen?
Als ik het bestand in adobe probeer te openen, krijg ik de melding dat er een fout is opgetreden tijdens het openen van het document. Het bestand is beschadigd en kan niet worden gerepareerd...
Welkom bij de NS Community, stienke.



Wat een vervelend probleem! Zou je het ticket eens willen proberen te openen met Foxit Reader? Mocht het probleem zich blijven voordoen wil ik je adviseren even contact op te nemen met onze Klantenservice via Twitter of Facebook of telefonisch via 030-7515155 (lokaal tarief).
Dag Stienke en Denice,



Afgelopen vrijdag 13 juli had ik hetzelfde probleem: 'lege' PDF als E-Ticket. De medewerkster van NS-Klantenservice herkende het probleem niet. Zij stuurde mij de link nogmaals. Helaas weer leeg.

Met 'print-screen' heb ik een afdruk van het reisgedeelte van het ticket gemaakt. Dit werd geaccepteerd bij de incheck-palen en door een conducteur. (Eindelijk weer eens gecontroleerd in de trein. Hoera😀 Zou vaker moeten gebeuren)

Het valt me tegen dat de medewerkster van NS-Klantenservice niet op de hoogte is van dit probleem én dat een PDF niet door Adobe gelezen kan worden. Actie-punt voor NS.

Een volgende keer zal ik Foxit reader proberen.
Als een PDF beschadigd is zal Foxit zich er waarschijnlijk ook in verslikken. Je hebt geluk gehad dat de conducteur het oké vond, want een screenshot van een PDF is niet geldig eigenlijk.

Edit: Sinds november 2018 mag een PDF wél!



Als de de NS Reisplanner app hebt, dan kan je alle NS e-tickets daar ook in laden door de e-mail te openen op je telefoon. Dat is wel geldig. Bij sommige actiekaartjes geldt nog wel de verplichting om te printen. Dit kan ook voor € 1,- bij een servicebalie op een station.
Als een PDF beschadigd is zal Foxit zich er waarschijnlijk ook in verslikken. Je hebt geluk gehad dat de conducteur het oké vond, want een screenshot van een PDF is niet geldig eigenlijk.



Als de de NS Reisplanner app hebt, dan kan je alle NS e-tickets daar ook in laden door de e-mail te openen op je telefoon. Dat is wel geldig. Bij sommige actiekaartjes geldt nog wel de verplichting om te printen. Dit kan ook voor € 1,- bij een servicebalie op een station.



Knappe conducteur die het verschil ziet tussen een print van een goed gemaakt screenshot van een pdf en een print van die pdf zelf... Ben er vrij zeker van het resultaat met hooguit wat bijsnijden en weer aan elkaar plakken exact gelijk te kunnen krijgen...



Overigens snap ik om bovenstaande reden ook niet waarom NS nog steeds verplicht om tickets te printen. Een pdf-document biedt echt een stuk meer mogelijkheden om de authenticiteit te controleren dan een bedrukt blaadje. Maar goed, dat is een heel ander punt.
NS blijft vasthouden aan zichtkenmerken, zowel bij afgedrukte e-tickets als mobile ticketing. Mobile tickets in de app zijn dan ook Secutix PDF's. En om die zichtkenmerken te kunnen handhaven wil men prints of app-imports hebben. Ik heb het ook niet bedacht.



Wanneer de geldigheid van een ticket gecontroleerd zou kunnen worden tegen een backoffice is dit hele circus sowieso niet meer nodig. Maarja..............
Op zich hoeft dat geen probleem te zijn Henk. Zelfs een continue verbinding met de backoffice is niet nodig.



(Zelfs na twee keer een hash algoritme en wat knipwerk heb je nog steeds voldoende informatie...🤔)
De zichtkenmerken op een op A4 uitgeprinte PDF zijn natuurlijk voor een geoefende HC in één oogopslag zichtbaar bij controle.



Als een PDF op je telefoon zou mogen dan moet je bij controle je telefoon aan de HC geven en die moet dan dan inzoomen en scrollen om de kenmerken te zien. Dat kost tijd en beginnen ze niet aan.



Ikzelf zou het ook niet prettig vinden om mijn telefoon uit handen te geven. Niet dat ik verwacht dat een HC hem stuk maakt of ermee aan de haal gaat, maar dat ding is van mij :)



Waarom het dan wel in de app mag, want daar staat toch precies hetzelde op? Dat is omdat er in de app rechtsonder een knopje "Omdraaien" zit. De helderheid gaat op maximaal en toont de Aztec code in de app.



Natuurlijk kan een hacker dat ook wel simuleren, maar is al een stuk lastiger.
De zichtkenmerken op een op A4 uitgeprinte PDF zijn natuurlijk voor een geoefende HC in één oogopslag zichtbaar bij controle.



Als een PDF op je telefoon zou mogen dan moet je bij controle je telefoon aan de HC geven en die moet dan dan inzoomen en scrollen om de kenmerken te zien. Dat kost tijd en beginnen ze niet aan.



Ikzelf zou het ook niet prettig vinden om mijn telefoon uit handen te geven. Niet dat ik verwacht dat een HC hem stuk maakt of er mee aan de haal gaat, maar dat ding is van mij :)



Waarom het dan wel in de app mag, want daar staat toch precies hetzelde op? Dat is omdat er in de app rechtsonder een knopje "Omdraaien" zit. Natuurlijk kan een hacker dat ook wel simuleren, maar is al een stuk veiliger en sneller te controleren.



Je neemt hier aan dat een pdf op een telefoon ook aan de hand van zichtbare kenmerken in het document gecontroleerd zou moeten worden. Dat levert inderdaad weinig tot geen winst op. Iets als een digitale handtekening is echter al een stuk makkelijker te controleren in de meeste pdf viewers en bovendien een stuk lastiger na te maken dan wat zichtbare kenmerken.



Op de oude treinkaartjes zaten zichtbare kenmerken in het papier op een manier die met een doorsnee printer niet na te maken is. Het hele idee idee van e-tickets die geprint moeten worden is echter juist dat ze wél met een doorsnee printer uit te printen zijn, inclusief de echtheidskenmerken. Impliciet volgt daaruit dat de echtheidskenmerken met een gewone printer te printen zijn, wat maakt dat deze documenten zonder specialistische apparatuur na te maken zijn.



Namaken van tickets blijft uiteraard gewoon strafbaar en wil ik zeker niet aanmoedigen, maar beveiliging zijn kenmerken die een gewone printer op gewoon papier kan drukken toch eigenlijk niet onder te scharen. Hacken zou hier overigens niet eens voor nodig zijn, dat is software met kwade bedoelingen op een andere manier gebruiken dan waar deze voor bedoeld is. Specifieke software is echter niet nodig om gewoon iets op papier te krijgen (en hoef je er dus ook niet voor te hacken, want er zijn vele programma's beschikbaar die gewoon bedoeld zijn om bepaalde afbeeldingen en stukken tekst op bepaalde plekken op een pagina te laten drukken.
Die zichtkenmerken zijn waardeloos, dat heb ik meermaals gedemonstreerd. Zowel mobiel als app als print. Maar men wil er per sé aan vast blijven houden. Het is net als de OV-chipkaart. Beperkte hoeveelheid fraude is financieel interessanter dan grote wijzigingen.



Terwijl de barcode prima versleuteling kent 😓
Dat er met die Aztec code nog niets gedaan wordt (behalve poortjes openen op de reisdatum) snap ik ook niet.



Het minste wat je (gewoon nu al) kunt doen is controleren op traject (bij de poortjes) maar ja, zolang de meeste stations helemaal geen poortjes hebben...
Op zich hoeft dat geen probleem te zijn Henk. Zelfs een continue verbinding met de backoffice is niet nodig.

Het is mij om 't even wat de implementatie is, zolang er maar validatie is van de informatie in de (string achter) de barcode. Of dat nou live is, updates in batches van een lokale db of whatever, het lost je probleem in ieder geval op. Om (de string achter) barcodes te genereren heb je immers toch de private key nodig. Misschien kunnen we wel iets gaafs op Mobitex bouwen en RAM nog een beetje sponsoren 🤣
Dat er met die Aztec code nog niets gedaan wordt (behalve poortjes openen op de reisdatum) snap ik ook niet.

Hij hoort wel netjes uitgelezen te worden bij controle, maar de zichtkenmerken werken nog als fallback wanneer nodig. Vrij recent was er nog gedoe hier op het forum omdat een tijdlang e-tickets printen vanuit Safari ervoor zorgde dat de barcode niet of verminkt op het ticket kwam. Dan kan er teruggevallen worden op zichtkenmerken en is de barcode dus waardeloos.
Okee, maar krijgen ze bij het uitlezen (met een MCLC) dan ook je persoonsgegevens en traject te zien?



Want dan zou het een veel minder groot probleem worden als je een PDF toont via een telefoon, in combinatie met je ID (jawel beste conducteur, dit ben ik!)



Ik begreep dat bij controle er al gelogd wordt, dus dat je niet twee keer op een dag met hetzelfde e-ticket kunt reizen.
Uit mijn hoofd traject/klasse/kaartsoort/geldigheidsdatum en naam en aantal. De geboortedatum zit uit mijn hoofd helemaal niet in de code verwerkt en ik dacht dat sinds een recente update er ook een melding verschijnt wanneer het ticket net aangeschaft is. Dat veld was eerst helemaal niet zichtbaar, wat mij verbaast, want het staat wel in de code.



En daar is geen enkel contact met een backoffice voor nodig, staat gewoon in de code. Maar dan moet je je er wel toe zetten om volledig op de code te vertrouwen, en bij een missende of verminkte barcode dat dus ook zien als ongeldig vvb.



In de code zit nog wat meer, waaronder prijs, eventueel een via die nu vaak gebruikt wordt voor de string "VRIJE VERVOERDERKEUZE", et cetera. Daarnaast zit er een ordernummer in wat gebruikt kan worden voor lookups in een database.



Is een UIC standaard, UIC918.2 en UIC918.3. Standaard is helaas niet openbaar, aantal implementaties wel.
Top, vooral dat "zojuist aangeschaft" is natuurlijk belangrijk, want daarmee is het tonen van een code uit een PDF i.p.v. op papier (met als excuus dat je printer thuis weigerde o.i.d.) alweer veel minder fraudegevoelig.
Als mijn geheugen meewerkt dan maakt men die vertaalslag inderdaad. Er zit in ieder geval een 'created at' in de string, dus je kunt de aanmaakdatum eruit afleiden.



In de luchtvaart is het droeviger qua etickets en de inhoud en beveiliging daarvan. Toch staat m'n Passbook vol met etickets en wandel je vrolijk door de poortjes ermee.
Is het trouwens een probleem als ik een e-ticket op mijn 9 naalds dot matrix printer afdruk? 🖨️️
Oh dat lijkt me wel gaaf, op ouderwets kettingpapier 😃
Uit mijn hoofd traject/klasse/kaartsoort/geldigheidsdatum en naam en aantal. De geboortedatum zit uit mijn hoofd helemaal niet in de code verwerkt en ik dacht dat sinds een recente update er ook een melding verschijnt wanneer het ticket net aangeschaft is. Dat veld was eerst helemaal niet zichtbaar, wat mij verbaast, want het staat wel in de code.



En daar is geen enkel contact met een backoffice voor nodig, staat gewoon in de code. Maar dan moet je je er wel toe zetten om volledig op de code te vertrouwen, en bij een missende of verminkte barcode dat dus ook zien als ongeldig vvb.



In de code zit nog wat meer, waaronder prijs, eventueel een via die nu vaak gebruikt wordt voor de string "VRIJE VERVOERDERKEUZE", et cetera. Daarnaast zit er een ordernummer in wat gebruikt kan worden voor lookups in een database.



Is een UIC standaard, UIC918.2 en UIC918.3. Standaard is helaas niet openbaar, aantal implementaties wel.



Leuke discussie over een van mijn vakgebieden. Ik ben een van de ontwikkelaars van het verkopend systeem. Jullie hebben een hoop al ontdekt. Ik heb m'n werktelefoon niet bij de hand, dus kan het niet checken, maar geboortedatum zou wel meegegeven moeten worden.



Daarnaast zijn we nu bezig met het reisrecht te verwerken in het ticket zodat mcl kan zien of dit ticket beperkingen heeft. De poortjes kunnen dat ook al, hier kennen we o.a. tijd- en regiobeperkingen. Nog wel prematuur overigens, want alles moet wel werken voor we dat aanzetten.



Overigens is Secutix al weer achterhaald 😉 Die hebben we begin dit jaar vervangen. Nu gaan we langzaamaan verder om de barcode te verbeteren. En klopt dat is de UIC 918.3 standaard, maar die laat nog heel veel aan interpretatie over. Laatst de vernieuwde versies (UIC 918.8 en 918.9) gelezen. Daar zit wel wat leuks in voor mobiele barcodes.


Uit mijn hoofd traject/klasse/kaartsoort/geldigheidsdatum en naam en aantal. De geboortedatum zit uit mijn hoofd helemaal niet in de code verwerkt en ik dacht dat sinds een recente update er ook een melding verschijnt wanneer het ticket net aangeschaft is. Dat veld was eerst helemaal niet zichtbaar, wat mij verbaast, want het staat wel in de code.



En daar is geen enkel contact met een backoffice voor nodig, staat gewoon in de code. Maar dan moet je je er wel toe zetten om volledig op de code te vertrouwen, en bij een missende of verminkte barcode dat dus ook zien als ongeldig vvb.



In de code zit nog wat meer, waaronder prijs, eventueel een via die nu vaak gebruikt wordt voor de string "VRIJE VERVOERDERKEUZE", et cetera. Daarnaast zit er een ordernummer in wat gebruikt kan worden voor lookups in een database.



Is een UIC standaard, UIC918.2 en UIC918.3. Standaard is helaas niet openbaar, aantal implementaties wel.Leuke discussie over een van mijn vakgebieden. Ik ben een van de ontwikkelaars van het verkopend systeem. Jullie hebben een hoop al ontdekt. Ik heb m'n werktelefoon niet bij de hand, dus kan het niet checken, maar geboortedatum zou wel meegegeven moeten worden.



Daarnaast zijn we nu bezig met het reisrecht te verwerken in het ticket zodat mcl kan zien of dit ticket beperkingen heeft. De poortjes kunnen dat ook al, hier kennen we o.a. tijd- en regiobeperkingen. Nog wel prematuur overigens, want alles moet wel werken voor we dat aanzetten.



Leuk.... 'Jullie hebben een hoop al ontdekt'



Jammer dat ........




Uit mijn hoofd traject/klasse/kaartsoort/geldigheidsdatum en naam en aantal. De geboortedatum zit uit mijn hoofd helemaal niet in de code verwerkt en ik dacht dat sinds een recente update er ook een melding verschijnt wanneer het ticket net aangeschaft is. Dat veld was eerst helemaal niet zichtbaar, wat mij verbaast, want het staat wel in de code.



En daar is geen enkel contact met een backoffice voor nodig, staat gewoon in de code. Maar dan moet je je er wel toe zetten om volledig op de code te vertrouwen, en bij een missende of verminkte barcode dat dus ook zien als ongeldig vvb.



In de code zit nog wat meer, waaronder prijs, eventueel een via die nu vaak gebruikt wordt voor de string "VRIJE VERVOERDERKEUZE", et cetera. Daarnaast zit er een ordernummer in wat gebruikt kan worden voor lookups in een database.



Is een UIC standaard, UIC918.2 en UIC918.3. Standaard is helaas niet openbaar, aantal implementaties wel.Leuke discussie over een van mijn vakgebieden. Ik ben een van de ontwikkelaars van het verkopend systeem. Jullie hebben een hoop al ontdekt. Ik heb m'n werktelefoon niet bij de hand, dus kan het niet checken, maar geboortedatum zou wel meegegeven moeten worden.



Daarnaast zijn we nu bezig met het reisrecht te verwerken in het ticket zodat mcl kan zien of dit ticket beperkingen heeft. De poortjes kunnen dat ook al, hier kennen we o.a. tijd- en regiobeperkingen. Nog wel prematuur overigens, want alles moet wel werken voor we dat aanzetten.Leuk.... 'Jullie hebben een hoop al ontdekt'



Jammer dat ........



Waarom jammer? Ik vind het leuk om te zien dat hier veel technische kennis zit met een hoop uitzoekvermogen 🙂
Gisteren weer inkt/toner en een vel papier verspild aan een (cadeautje wegens overmacht, bedankt nogmaals ^ET @Erryt NS) 1e klas dagkaartje.



Had het ticket ook wel in de app natuurlijk, maar toch ook maar uitgeprint voor de zekerheid, want stel je zomaar voor dat de accu van mijn telefoon leeg zou raken en er geen stopcontacten zijn in de 1e klas onderweg 😃
@RR,

Dat laatste begrijp ik.

Probleem is dat er met de inbreng van leden t.a.v. dit soort topics niks gedaan wordt. En dat is jammer. Heel jammer. Sorry dat ik het zo formuleer. Wat vind je zelf van hele e-ticket systeem en controle? Kan het systeem niet simpeler en beter?
Dat laatste begrijp ik.

Probleem is dat er met de inbreng van leden t.a.v. dit soort topics niks gedaan wordt. En dat is jammer. Heel jammer. Sorry dat ik het zo formuleer. Wat vind je zelf van hele e-ticket systeem en controle? Kan het systeem niet simpeler en beter?



Ja, dat kan simpeler en beter. Gaat daar tijd overheen? Ja, daar gaat tijd overheen. Wij willen het graag in onze app hebben, zodat we kunnen zorgen dat je telefoon zich aanpast aan de situatie: 100% helderheid, geen NFC chip en niet draaien. Zie je het al voor je als Miep met een telefoon voor het poortje staat die constant draait en van grootte wisselt? Krijg je superlange rijen bij die poortjes van hoor.



Dan heb je nog het stuk dat sommige tickets niet in de app te laden zijn. Klopt. Dat heeft diverse oorzaken. De meeste hebben te maken met de Spoordeelwinkelcoupon's die als kwart op de PDF staat. Die kan nog niet in de app getoond worden. Zijn we al wel mee bezig, maar dan heb je weer bedrijven die niet van een telefoon kunnen scannen. Oeps, hoe doe je dat dan? Of gewoon contracten die het nog steeds over homeprint hebben en eerst opnieuw onderhandeld moeten worden.



Derde onderwerp is bijvoorbeeld de Spoordeelwinkel en waarom die suffe coupons opleveren die weer moet inwisselen op de NS site voor je ticket. Een doorn in m'n oog. Ook daar zijn we mee bezig. Bijvoorbeeld door derden (zoals Kruidvat, Vakantieveiligen e.d.) direct bij ons een order aan te laten maken. Dan loopt je weer tegen AVG en bewerkingsovereenkomsten aan.



Dus: ja, het kan simpeler en beter en daar zetten we ook vol op in. Het team waar ik in zit is dit jaar in grootte verdubbeld om dat voor elkaar te krijgen.



Overigens is de frustratie in mijn post niet naar jou gericht @Nooduitgang 😉

Reageer


Voorwaarden