Security Professionals
- ipfw add deny all from eindgebruikers to any
PGO's: minister Agema liegt
TL;DR: zie de conclusie (Nb. quote niet dit hele artikel als je reageert!)
Stelling: i.r.t. PGO's liegt minister Agema dat zij barst
Onder het redactie-artikel "Minister: curator verantwoordelijk dat failliete PGO-leverancier AVG naleeft schreef ik (in https://security.nl/posting/883576):Door Erik van Straten:
"Je gegevens zijn van jezelf en die blijven bij de bron. Op het moment dat de app weg is, zijn de gegevens ook weg", laat ze tegenover Meldpunt weten.
Meerdere glasharde leugens van minister Agema. Dat noemen we ook wel volksverlakkerij.Laat ik mijn bovenstaande stelling (leugens en volksverlakkerij) maar weer eens onderbouwen. Zodat ook U, de lezer, weet waarom de AVG een curator (of een PGO-aanbieder zelf) geen strobreed in de weg legt indien zij uw persoons- en/of medische gegevens te verkopen (de curator bijv. om daarmee eisers schadeloos te stellen, of de PGO-eigenaar om een dikke Audi te kunnen kopen).
'Eigenaarschap van gegevens bestaat niet'
Op 5-10-2017 blogde Ron Roozendaal, op dat moment directeur Informatiebeleid bij het ministerie van Volksgezondheid, onverbloemd in https://www.ronroozendaal.nl/blog/tag/eigendom:Steeds vaker hoor ik mensen zeggen: ik wil eigenaar zijn van mijn medische gegevens. Ik vind dat bijzonder, en het kan ook helemaal niet.
[...]
[...]
ICT-jurist Arnoud Engelfriet deelt de mening van Ron Roozendaal: "data is niets" en heeft dus geen eigenaar. Zie bijv. https://tweakers.net/nieuws/198684/#r_17684994 (na een cookie-melding moet je die link mogelijk opnieuw openen) en https://tweakers.net/reviews/10340/data-is-niets-de-juridische-status-van-digitale-diensten.html?showReaction=17775272#r_17775272 (Nb. sinds ik mijn Tweakers-account heb opgezegd, is -ondanks mijn drongende verzoek- geen van mijn postings verwijderd, maar is "ErikvanStraten" boven al mijn writings veranderd in "Anoniem: 1576590" op die site).
Juridisch gezien bent u dus geen eigenaar van gegevens over u. De AVG (afgeleid van de GDPR) is een poging om misbruik te voorkómen, maar zit vol mazen, naast dat er veel te veel "regels" voor meerderlei uitleg vatbaar zijn.
Uit https://www.rtl.nl/nieuws/economie/artikel/5474470/knltb-wint-europese-zaak-van-ap van 8 oktober 2024:
Het is als sportbond of andere organisatie niet per definitie verboden om gegevens van leden te verkopen aan bedrijven. Dit heeft het Europese Hof van Justitie bepaald in een zaak waar de Nederlandse tennisbond KNLTB en de Nederlandse Autoriteit Persoonsgegevens (AP) centraal stonden. "Deze uitspraak kan grotere gevolgen hebben."
Ook van Huffelen loog - tegen de hele wereld
Niet alleen Agema maar ook voormalig staatssecretaris van Huffelen loog; op de G20 op Bali (Indonesië) zei zij:"Het is essentieel dat burgers zelf de regie hebben en houden over wat er met hun data gebeurt en met wie gegevens worden gedeeld. Het is hun data en daarover moeten mensen zelf altijd het laatste woord hebben."
Ook tegen de Tweede Kamer loog zij, URL's vindt u in https://security.nl/posting/786482.Beleidsmakers buitelen over elkaar heen met leugen op leugen. Met de EHDS vervalt het medisch beroepsgeheim en zullen phishing-aanvallen alleen maar toenemen
Afko's voor het volgende
PGO-a: PGO-aanbiederP: patient
Z: zorgverlener
Nb. sla onderstaande theoriën gerust over (zij beschrijven niet de praktijk).
Theorie: met app, data buiten PGO-a om
In theorie zou een PGO-a slechts een "identiteitsverifieerder en -bewijzer" kunnen zijn, die de identiteit van P op voldoende betrouwbare wijze vaststelt.Mogelijk (maar uiterst onwaarschijnlijk) is dat de PGO-app van P, na installatie, een asymmetrisch sleutelpaar heeft gegenereerd en PGO-a heeft bevestigd dat de publieke sleutel van P is, waarna PGO-a die publieke sleutel + identificerende gegevens van P opneemt in een (door PGO-a digitaal ondertekend X.509) certificaat, en dat certificaat terugstuurt naar de app.
Zodra P, met diens app, gegevens bij Z opvraagt, bewijst het door PGO-a afgegeven certificaat dat P is wie zij/hij zegt te zijn, waarna Z de gevraagde medische gegevens van P ontsluit (voorwaarde is dat Z vertrouwen heeft in PGO-a, wat vaak niet het geval was/is - waarom zou Z erop vertrouwen dat de processen bij PGO-a voldoende betrouwbaar zijn; bijv. een "ce" keurmerk, zoals gebruikt door Topicus, zou zelfs averechts moeten werken: zie https://security.nl/posting/842899 en https://security.nl/posting/871958).
Vervolgens gebruikt Z de publieke sleutel van P om de medische gegevens mee te versleutelen (*). Hierdoor kan uitsluitend de bezitter van de private key (de app van P) die gegevens ontsleutelen.
(*) Asymetrische cryptografie is ongeschikt om grote hoeveelheden bytes mee te versleutelen. In de praktijk wordt een random symmetrische (vaak AES) sleutel gegenereerd waarmee de data worden versleuteld. Daarnaast wordt de symmetrische sleutel met de public key versleuteld, en beide versleutelde sets worden geretourneerd. Uitsluitend de bezitter van de private key uit het sleutelpaar kan de symmetrische sleutel ontsleutelen, en daarmee de medische gegevens.
In dit scenario vraagt de app van P de medische gegevens zelf op bij Z en vallen deze dus niet in handen van PGO-a. Of en hoe lang de app lokaal een kopie van die gegevens opslaat (caching) is irrelevant bij het faillisement van PGO-a.
Nb. PGO-a beschikt waarschijnlijk wel over uiterst risicovolle identificerende en identiteit "aantonende" gegegens van P. De curator kan besluiten om dergelijke persoonsgegevens te verkopen, om daarmee eisers schadeloos te kunnen stellen.
Theorie: met app, data versleuteld "langs" PGO-a
In plaats van dat de app zelf Z benadert, kan dat ook via de PGO-a. Die PGO-a zou de versleutelde data vervolgens kunnen cachen, zodat deze niet telkens opnieuw bij Z hoeft te worden opgehaald.Om het "niet up-to-date zijn" te voorkomén, kan Z een datum+tijdstempel plus dataset-identifier (beide onversleuteld) meezenden. Indien P gegevens wil inzien, kan PGO-a, met die gegevens, bij Z navragen of de gegevens, sinds de laatste keer ophalen, zijn gewijzigd (en de gecachte dataset zonodig verversen).
Theorie: met website, data versleuteld
Als P de app niet of niet in alle gevallen gebruikt, is het -in theorie- zelfs mogelijk dat PGO-a en haar website uitsluitend versleutelde data verwerken, die door Z versleuteld is en door de browser van P ontsleuteld wordt.Maar daarvoor moet PGO-a Javascript naar uw browser sturen. Elke keer dat dit gebeurt zult u erop moeten vertrouwen dat die code niet is gewijzigd zodat onversleutelde data alsnog bij PGO-a en/of derden terechtkomt.
Bij het gebruik van een app geldt dit ook bij elke update daarvan.
PGO's in de praktijk
Commerciële organisaties maken voortdurend afwegingen over hún versus úw belangen en risico's.Zij kunnen, ook voor u, meerwaarde leveren indien zij alle informatie die zij van en over u hebben, kunnen ontsleutelen. U kunt dan bijv. chronologische overzichten maken van bezoeken aan meerdere Z of andere correlaties onderzoeken, of zoeken in uw gedeeltelijke of gehele medische geschiedenis. Veel eenvoudiger en dus voordeliger is het als de PGO-a al die informatie onversleuteld opslaan (**), bij voorkeur in een database waarin eenvoudig gezocht en gerelateerd kan worden.
Bij apps is het gebruikelijk dat de meeste verwerkingen op één of meer servers plaatsvinden. Immers, niet elke smartphone heeft veel geheugen en een snelle CPU. Daarnaast is het voor leveranciers veel eenvoudiger om centraal (op servers) wijzigingen door te voeren dan in apps, vooral als gebruikers oudere versies daarvan blijven gebruiken. Veel apps zijn daarom niet of nauwelijks meer dan een browser-engine waarbij u niet zelf URL's kunt invoeren.
Kortom, zelfs als een PGO-a uw gegevens zelf versleutelt, hebben zij ook de benodigde decryptie-sleutels "onder de deurmat" (tenzij zij niet meer zijn dan een doorgeefluik van versleutelde data, maar die kans lijkt mij nul als de data ook via een website benaderbaar is, en zeer klein indien uitsluitend een app kan worden gebruikt).
(**) Misleidende privacy-verklaringen
Een gebruikelijke truc daarbij is om (bijv. in een privacy-verklaring) te claimen dat uw data versleuteld is tijdens transport (dat geldt echter uitsluitend voor specifiek die verbindingen die gebruik maken van TLS, waaronder https, maar dat betreft nooit alle verbindingen) en tijdens opslag "at rest". Dat laatste is een halve waarheid: als het allemaal goed gaat, kan iemand die onbedoeld zo'n opslagmedium in handen krijgt de data daarop niet ontsleutelen, maar "live" (in gebruik in servers) is dergelijke data gewoon toegankelijk (een "hacker" kan daar dus gewoon bij, zonder een sleutel nodig te hebben).
Een gebruikelijke truc daarbij is om (bijv. in een privacy-verklaring) te claimen dat uw data versleuteld is tijdens transport (dat geldt echter uitsluitend voor specifiek die verbindingen die gebruik maken van TLS, waaronder https, maar dat betreft nooit alle verbindingen) en tijdens opslag "at rest". Dat laatste is een halve waarheid: als het allemaal goed gaat, kan iemand die onbedoeld zo'n opslagmedium in handen krijgt de data daarop niet ontsleutelen, maar "live" (in gebruik in servers) is dergelijke data gewoon toegankelijk (een "hacker" kan daar dus gewoon bij, zonder een sleutel nodig te hebben).
Gaat het om de echte PGO-a?
Als u een account aanmaakt en inlogt bij een PGO-a is het enorm belangrijk dat u voldoende zeker weet dat u een website met de exact correcte domeinnaam hebt geopend. Alle PGO-a's die ik heb gecheckt (dat is alweer meer dan een jaar geleden, maar ik verwacht beslist geen verbetering) gebruikten "Domain Validated" certificaten waarin betrouwbare identificerende gegevens over de verantwoordelijke ontbreken. Daarbij worden soms absurde domeinnamen gebruikt. Daarom kunnen zowel nieuwkomers als bestaande klanten eenvoudig gephished worden.Gaat het om de echte patiënt P?
Mede vanwege het vorige punt, maar ook omdat niet elke PGO-a BSN's mag verwerken én omdat online authenticatie per definitie onbetrouwbaar is, bestaat er een flinke kans op identiteitsfraude. Vooral voor "bankhelpdeskfraudeurs" is het interessant om over zoveel mogelijk gegevens van (voor oplichting) kwetsbare mensen te beschikken. Als zij zich als hun potentiële slachtoffer kunnen voordoen richting een PGO-a, kunnen zij veel aanvullende vertrouwelijke gegevens "binnenhengelen".PGO's waren niks en worden niks
Uit 2018 in https://tweakers.net/nieuws/141855/:Veel Nederlandse artsen en zorgverleners zijn bezorgd over de opvolger van het elektronisch patiëntendossier. De pgo, ofwel de persoonlijke gezondheidsomgeving, heeft volgens onderzoeksjournalisten mede daarom weinig kans van slagen.
Uit https://www.artsenauto.nl/haal-vandaag-nog-uw-gegevens-op/ van juni 2023:
‘Wij zijn niet telefonisch bereikbaar en bieden ook niet de mogelijkheid om door ons [sic] gebeld te worden’
Opnieuw leesvoer door Ron Roozendaal, in jan. 2021, uit https://www.ronroozendaal.nl/blog/2023/01/werken-aan-de-digitale-bewijspas:
Vandaag schreef Follow the Money over de ontwikkeling van een “wallet” door de overheid. Of, zoals zij het noemen, de digitale bewijspas. Ik ben daarbij betrokken, en dus vast bevooroordeeld.
Uit https://www.security.nl/posting/776776/Minister+wil+niet+met+AP+in+gesprek+over+schrappen+van+AVG-boete+KNLTB#posting776804 over de tennisbond en PGO VitaalBank die destijds in hun privacyverklaring expliciet schreef:
We kunnen je gegevens ook verwerken omdat dit noodzakelijk is om onze diensten aan je te kunnen aanbieden, omdat dit noodzakelijk is om te voldoen aan een wettelijke plicht die op ons rust of als dit noodzakelijk is voor onze gerechtvaardigde belangen.
In https://tweakers.net/nieuws/204604/irma-ontwikkelaar-sidn-neemt-deel-aan-eu-pilot-voor-digitale-identiteitswallet.html?showReaction=18259572#r_18259572 leest u verder hoe ik over de veiligheid en betrouwbaarheid van IRMA/Yivi en PGO's dacht (en nog steeds denk).
CONCLUSIE
1) Gegevens van/over jou zijn niet van jou. Het verkopen van "jouw" gegevens kan een "gerechtvaardigd" belang zijn van "ondernemers". Vooral van (bijna) failliete. En wie zou je daarna aan moeten klagen?2) Je gegevens blijven nooit alleen bij de bron. Ze komen sowieso naar het apparaat met browser en/of app en worden daar meestal gecached. De kans dat elke PGO-a daar een kopie van heeft en bewaart schat ik op bijna 100%.
3) Het verwijderen van een app heeft, in waarschijnlijk alle gevallen, geen effect op bij derden opgeslagen gegevens die ooit in die app zijn getoond (het kan zelfs om veel meer gegevens gaan indien de server heeft gefilterd en er een selectie naar de app is gestuurd).
Kortom, minister Agema liegt over alle drie de aspecten dat zij barst. Trap niet in de leugens van suf-gelobbiede (en mogelijk corrupte) -en vaak het bedrijfsleven ondersteunende- politici!
Reacties (13)
Ik denk dat je conclusies terecht zijn.
Dat de PGO-a een kopie heeft van deze gegevens in een of andere cache is denk ik een zekerheid (immers, anders zou bij het opvragen van zo'n dossier een uitstapje naar alle aangesloten Z's moeten worden gemaakt). Als deze cache al versleuteld is is dat, als ik zie hoe er met deze gegevens in de praktijk wordt omgegaan (ongeacht AVG, ISO27, NEN-normen etc), heel onwaarschijnlijk dat dit op de end-2-end manier (zoals je beschrijft in het versleutelen van de data met de public key van P) plaatsvindt. Ik zie vaak dat versleuteling (want dat moet van de normen) plaatsvindt door disk-encryptie toe te passen (en in een aantal gevallen database-file encryptie); ik kom bijna nooit applicatieve encryptie tegen. Dat houdt dan in dat (a) de PGO-a toegang heeft tot de sleutel (en dus de data) en (b) dat de beheerder/DBA zelfs zonder sleutel toegang heeft.
Verwijderen van een app heeft sowieso geen effect op de data aan de server kant: dit is gewoon een client-side activiteit (een reinstall van de app zal in veel gevallen denk ik ook niet meer voeten in aarde hebben dan opnieuw inloggen bij de server).
Tenslotte. In haar kamerlidtijd was Agema een groot voorstander om de patient volledig de regie over de data te geven (ik herinner me zelfs een debat waarin ze vroeg of een dossier niet uitgewisseld kon worden door de patient een USB-stick mee te geven met deze data erop ipv online uitwisseling, als de patient dat wilde). Nu ze de smaak van het pluche heeft geproeft is ze 180 graden gedraaid.
Dat de PGO-a een kopie heeft van deze gegevens in een of andere cache is denk ik een zekerheid (immers, anders zou bij het opvragen van zo'n dossier een uitstapje naar alle aangesloten Z's moeten worden gemaakt). Als deze cache al versleuteld is is dat, als ik zie hoe er met deze gegevens in de praktijk wordt omgegaan (ongeacht AVG, ISO27, NEN-normen etc), heel onwaarschijnlijk dat dit op de end-2-end manier (zoals je beschrijft in het versleutelen van de data met de public key van P) plaatsvindt. Ik zie vaak dat versleuteling (want dat moet van de normen) plaatsvindt door disk-encryptie toe te passen (en in een aantal gevallen database-file encryptie); ik kom bijna nooit applicatieve encryptie tegen. Dat houdt dan in dat (a) de PGO-a toegang heeft tot de sleutel (en dus de data) en (b) dat de beheerder/DBA zelfs zonder sleutel toegang heeft.
Verwijderen van een app heeft sowieso geen effect op de data aan de server kant: dit is gewoon een client-side activiteit (een reinstall van de app zal in veel gevallen denk ik ook niet meer voeten in aarde hebben dan opnieuw inloggen bij de server).
Tenslotte. In haar kamerlidtijd was Agema een groot voorstander om de patient volledig de regie over de data te geven (ik herinner me zelfs een debat waarin ze vroeg of een dossier niet uitgewisseld kon worden door de patient een USB-stick mee te geven met deze data erop ipv online uitwisseling, als de patient dat wilde). Nu ze de smaak van het pluche heeft geproeft is ze 180 graden gedraaid.
10-04-2025, 10:25 door
Named
Redelijk goede conclusie, vind ik.
Natuurlijk volgt dan de vraag: en wat nu?
- Hoe zorgen we dat onze gegevens "van ons" blijven?
(Ofwel, hoe maken we de verkoop ervan een niet-gerechtvaardigd belang?)
Additioneel, hoe voorkomen of beheren we de verspreiding van onze gegevens?
- Verwijderen van een app zou een datavernietigingsprocedure moeten starten.
Een verwijderde app kan niks meer, dus het OS zal hiervoor functionaliteit moeten inbouwen.
- We hebben blijkbaar een corrupte/"gelobbyde" minister die loopt te liegen. Hier moet wat mee gebeuren.
Wie of welke instantie is verantwoordelijk om zulke (potentiële) corruptie te onderzoeken, waar kunnen we dit melden?
Natuurlijk volgt dan de vraag: en wat nu?
- Hoe zorgen we dat onze gegevens "van ons" blijven?
(Ofwel, hoe maken we de verkoop ervan een niet-gerechtvaardigd belang?)
Additioneel, hoe voorkomen of beheren we de verspreiding van onze gegevens?
- Verwijderen van een app zou een datavernietigingsprocedure moeten starten.
Een verwijderde app kan niks meer, dus het OS zal hiervoor functionaliteit moeten inbouwen.
- We hebben blijkbaar een corrupte/"gelobbyde" minister die loopt te liegen. Hier moet wat mee gebeuren.
Wie of welke instantie is verantwoordelijk om zulke (potentiële) corruptie te onderzoeken, waar kunnen we dit melden?
10-04-2025, 11:36 door
Anoniem
Door Named:
[...]
- We hebben blijkbaar een corrupte/"gelobbyde" minister die loopt te liegen. Hier moet wat mee gebeuren.
Wie of welke instantie is verantwoordelijk om zulke (potentiële) corruptie te onderzoeken, waar kunnen we dit melden?
Verantwoordelijk is de burger die hiervoor gestemd heeft[...]
- We hebben blijkbaar een corrupte/"gelobbyde" minister die loopt te liegen. Hier moet wat mee gebeuren.
Wie of welke instantie is verantwoordelijk om zulke (potentiële) corruptie te onderzoeken, waar kunnen we dit melden?
en de (andere) politieke partijen die hier in zijn meegegaan.
Dat kun je hier en op andere zgn. sociale media melden.
10-04-2025, 11:53 door
Anoniem
Door majortom:
Dat de PGO-a een kopie heeft van deze gegevens in een of andere cache is denk ik een zekerheid (immers, anders zou bij het opvragen van zo'n dossier een uitstapje naar alle aangesloten Z's moeten worden gemaakt).
Dat gebeurt. In elk geval, als het systeem van een zorgaanbieder eruit ligt is, in mijn ervaring, de data van die zorgaanbieder direct niet zichtbaar in het PGO. Want iedere keer dat je het inziet wordt het opgehaald bij de zorgaanbieder.Dat de PGO-a een kopie heeft van deze gegevens in een of andere cache is denk ik een zekerheid (immers, anders zou bij het opvragen van zo'n dossier een uitstapje naar alle aangesloten Z's moeten worden gemaakt).
10-04-2025, 12:15 door
Erik van Straten
Door Anoniem:
Alleen betrokkenen weten hoe dit werkt. Het is heel goed mogelijk dat er wel degelijk gecached wordt door de PGO-a, maar dat deze probeert te checken of de door hen gecachte data nog up-to-date is. En als dat niet lukt, veiligheidshalve (of om de door jou veronderstelde suggestie te wekken) - geen gegevens van die Z toont, al dan niet voorzien van foutmelding.Door majortom:
Dat de PGO-a een kopie heeft van deze gegevens in een of andere cache is denk ik een zekerheid (immers, anders zou bij het opvragen van zo'n dossier een uitstapje naar alle aangesloten Z's moeten worden gemaakt).
Dat gebeurt. In elk geval, als het systeem van een zorgaanbieder eruit ligt is, in mijn ervaring, de data van die zorgaanbieder direct niet zichtbaar in het PGO. Want iedere keer dat je het inziet wordt het opgehaald bij de zorgaanbieder.Dat de PGO-a een kopie heeft van deze gegevens in een of andere cache is denk ik een zekerheid (immers, anders zou bij het opvragen van zo'n dossier een uitstapje naar alle aangesloten Z's moeten worden gemaakt).
Dat is goed gebruik bij caching, en standaard in browsers en bijv. bij de checks die Windows doet bij opstarten - o.a. of er wijzigingen in op de PC gecachte rootcertificaten moeten worden doorgevoerd.
Kortom, een foutmelding o.i.d. bij een onbereikbare Z is geen bewijs dat er niet gecached wordt.
10-04-2025, 13:35 door
Anoniem
Door Erik van Straten:
Alleen betrokkenen weten hoe dit werkt. Het is heel goed mogelijk dat er wel degelijk gecached wordt door de PGO-a, maar dat deze probeert te checken of de door hen gecachte data nog up-to-date is. En als dat niet lukt, veiligheidshalve (of om de door jou veronderstelde suggestie te wekken) - geen gegevens van die Z toont, al dan niet voorzien van foutmelding.
(...)
Kortom, een foutmelding o.i.d. bij een onbereikbare Z is geen bewijs dat er niet gecached wordt.
Dit is een omdraaiing van bewijslast. Ik reageer op iemand die de claim maakt dat "caching bij PGO-a een zekerheid is". En daarbij het argument aandraagt dat "Anders er bij elke inzage een uitstap naar zorgverleners gemaakt moet worden". Dat argument kan sowieso de prullenbak in, want dat er bij elke inzage een uitstap naar de zorgverleners gemaakt wordt is een feit.Alleen betrokkenen weten hoe dit werkt. Het is heel goed mogelijk dat er wel degelijk gecached wordt door de PGO-a, maar dat deze probeert te checken of de door hen gecachte data nog up-to-date is. En als dat niet lukt, veiligheidshalve (of om de door jou veronderstelde suggestie te wekken) - geen gegevens van die Z toont, al dan niet voorzien van foutmelding.
(...)
Kortom, een foutmelding o.i.d. bij een onbereikbare Z is geen bewijs dat er niet gecached wordt.
Verder snap ik dat je mij niet op mijn blauwe ogen gelooft, maar ik ben betrokken genoeg om te weten dat het echt gaat om een koppelvlak waar de data elke keer live opgehaald wordt.
Het nut van caching gaat ook een beetje verloren als je de gecachete data alleen kan gebruiken, nadat je de gecachete data toch opnieuw opgehaald hebt.
10-04-2025, 18:19 door
Erik van Straten
Door Anoniem: Het nut van caching gaat ook een beetje verloren als je de gecachete data alleen kan gebruiken, nadat je de gecachete data toch opnieuw opgehaald hebt.
Klopt. Maar zoals ik schreef, caching met checken of data up-to-date is, is veel efficiënter.Daarnaast werken servers bijna altijd met databases, en zelfs als je records na een sessie weer "verwijdert", betekent dat geenszins dat de bytes waar die records uit bestonden, betrouwbaar worden overschreven.
Overschrijven is trouwens nauwelijks mogelijk bij flash-geheugen zoals in SSD's. Naast dat de meeste computers gebruikmaken van virtueel geheugen, en het bijna niet te voorspellen is wat waar in paging-files belandt.
Dat allemaal nog los van een kwaadwillende beheerder, of de baas van PGO-a die kopietjes maakt of laat maken. Iets dat minder eenvoudig is in de theoretische scenario's die ik beschreef. Maar, linksom of rechtsom, is een PGO-a een MitM (Man in the Middle).
Ikzelf peins er in elk geval niet over om mijn medische gegevens aan een partij toe te vertrouwen die ik niet zelf betaal, die alle mogelijke moeite doet om zo anoniem mogelijk te blijven, en/of met een"ce" keurmerk mijn vertrouwen probeert te winnen.
10-04-2025, 22:33 door
Anoniem
Door Erik van Straten:
Hoe is dat efficienter? Het staat gelijk aan niet cachen, want je cache wordt nooit gebruikt. Door Anoniem: Het nut van caching gaat ook een beetje verloren als je de gecachete data alleen kan gebruiken, nadat je de gecachete data toch opnieuw opgehaald hebt.
Klopt. Maar zoals ik schreef, caching met checken of data up-to-date is, is veel efficiënter.Ofwel je data is niet meer up to date, dus je gebruikt de nieuwe data en niet je cache.
Ofwel je data is wel up to date. Leuk, maar je hebt de data al opnieuw opgehaald, dus waar dient de cache dan nog voor?
Ofwel, er treedt ergens een fout op waardoor de live data niet opgehaald kan worden. In het scenario dat je voorstelt, wordt de cache dan ook niet gebruikt, want hij kon niet geverifiëerd worden.
In geen scenario biedt de cache enig voordeel.
Door Erik van Straten:
Daarnaast werken servers bijna altijd met databases, en zelfs als je records na een sessie weer "verwijdert", betekent dat geenszins dat de bytes waar die records uit bestonden, betrouwbaar worden overschreven.
Overschrijven is trouwens nauwelijks mogelijk bij flash-geheugen zoals in SSD's. Naast dat de meeste computers gebruikmaken van virtueel geheugen, en het bijna niet te voorspellen is wat waar in paging-files belandt.
Dat (restanten van) data op allerlei plekken achterblijven en achterhaald zouden kunnen worden heb ik ook nooit betwist. Ik heb gereageerd op een bewering over caching. Dat is: ervoor kiezen data tijdelijk te bewaren om deze in die periode sneller opnieuw te kunnen serveren.Daarnaast werken servers bijna altijd met databases, en zelfs als je records na een sessie weer "verwijdert", betekent dat geenszins dat de bytes waar die records uit bestonden, betrouwbaar worden overschreven.
Overschrijven is trouwens nauwelijks mogelijk bij flash-geheugen zoals in SSD's. Naast dat de meeste computers gebruikmaken van virtueel geheugen, en het bijna niet te voorspellen is wat waar in paging-files belandt.
11-04-2025, 08:28 door
Anoniem
Mooi. Als data niets is kan ik weer vrijuit data uitwisselen met mijn vrinden. Data heeft geen eigenaar en dus kan Tom Cruise mij niets maken als ik Top Gun 3 ga torrenten.
Helaas,
In werkelijkheid is er met het auteursrecht in de hand een zeer sterke case te maken voor het eigenaarschap, en alle rechten die daar bij horen, van data die mij persoonlijk betreft. Immers, al die data is aan mij ontsproten, net zoals het script van Top Gun 3 aan de schrijver's fantasie is ontsproten.
Het auteursrecht wordt automatisch toegekend zodra er gecreeerd wordt. Er hoeft geen verdere actie ondernomen te worden.
Hetzelfde geldt m.i. voor datacreatie waarbij ik het onderwerp ben. Dat is een zogenaamd werk van wetenschap en ik heb dat veroorzaakt, niet degene die het toevallig codeert in bits.
https://wetten.overheid.nl/BWBR0001886/2025-02-04
Helaas,
In werkelijkheid is er met het auteursrecht in de hand een zeer sterke case te maken voor het eigenaarschap, en alle rechten die daar bij horen, van data die mij persoonlijk betreft. Immers, al die data is aan mij ontsproten, net zoals het script van Top Gun 3 aan de schrijver's fantasie is ontsproten.
Het auteursrecht wordt automatisch toegekend zodra er gecreeerd wordt. Er hoeft geen verdere actie ondernomen te worden.
Hetzelfde geldt m.i. voor datacreatie waarbij ik het onderwerp ben. Dat is een zogenaamd werk van wetenschap en ik heb dat veroorzaakt, niet degene die het toevallig codeert in bits.
https://wetten.overheid.nl/BWBR0001886/2025-02-04
11-04-2025, 11:38 door
Anoniem
Door Anoniem:
Ofwel je data is niet meer up to date, dus je gebruikt de nieuwe data en niet je cache.
Ofwel je data is wel up to date. Leuk, maar je hebt de data al opnieuw opgehaald, dus waar dient de cache dan nog voor?
Ofwel, er treedt ergens een fout op waardoor de live data niet opgehaald kan worden. In het scenario dat je voorstelt, wordt de cache dan ook niet gebruikt, want hij kon niet geverifiëerd worden.
In geen scenario biedt de cache enig voordeel.
In een HTTP-request kan een client een header "If-Modified-Since" met een datum/tijd opnemen. Als wat de client opvraagt bij de server nieuwer is dan die datum en tijd krijgt die het volledig terug, met een HTTP-responsecode 200. Als het ouder is dan geeft de server HTTP-responsecode 304 terug en slaat die de gevraagde inhoud over, er worden dan alleen response-headers teruggegeven. De opgegeven datum/tijd hoort natuurlijk bij wat de client in de cache heeft staan. Zo ziet de client aan het antwoord van de server of die de cache moet gebruiken, en de server moet daarvoor weliswaar een request verwerken, maar zowel de netwerkverbinding als de server zelf worden minder belast als de inhoud niet opnieuw hoeft te worden doorgegeven.Door Erik van Straten: Klopt. Maar zoals ik schreef, caching met checken of data up-to-date is, is veel efficiënter.
Hoe is dat efficienter? Het staat gelijk aan niet cachen, want je cache wordt nooit gebruikt. Ofwel je data is niet meer up to date, dus je gebruikt de nieuwe data en niet je cache.
Ofwel je data is wel up to date. Leuk, maar je hebt de data al opnieuw opgehaald, dus waar dient de cache dan nog voor?
Ofwel, er treedt ergens een fout op waardoor de live data niet opgehaald kan worden. In het scenario dat je voorstelt, wordt de cache dan ook niet gebruikt, want hij kon niet geverifiëerd worden.
In geen scenario biedt de cache enig voordeel.
Het is dus niet een keuze tussen alles of niets, er zit nog een variant tussen die de belasting van de server en zijn internetverbinding verlaagt. Dus ja, caching heeft zin en is sneller.
Ik weet niet of het hele traject naar de bron van de data bij zo'n PGO via HTTPS loopt, maar in andere communicatieprotocollen kunnen vergelijkbare mogelijkheden zitten.
Door Anoniem:
Je hebt duidelijk géén idee hoe online caching, van mogelijk wijzigende data, werkt. En je leest niet wat ik schrijf, maar roeptoetert wél. Hoe noemen we zo iemand ook alweer?Door Erik van Straten:
Hoe is dat efficienter? Het staat gelijk aan niet cachen, want je cache wordt nooit gebruikt.Door Anoniem: Het nut van caching gaat ook een beetje verloren als je de gecachete data alleen kan gebruiken, nadat je de gecachete data toch opnieuw opgehaald hebt.
Klopt. Maar zoals ik schreef, caching met checken of data up-to-date is, is veel efficiënter.Lees nu eens wél wat ik eerder schreef, dat ook geldt voor niet versleutelde gecachte data:
Door Erik van Straten: Om het "niet up-to-date zijn" te voorkomén, kan Z een datum+tijdstempel plus dataset-identifier (beide onversleuteld) meezenden. Indien P gegevens wil inzien, kan PGO-a, met die gegevens, bij Z navragen of de gegevens, sinds de laatste keer ophalen, zijn gewijzigd (en de gecachte dataset zonodig verversen).
en laterDoor Erik van Straten: Het is heel goed mogelijk dat er wel degelijk gecached wordt door de PGO-a, maar dat deze probeert te checken of de door hen gecachte data nog up-to-date is. En als dat niet lukt, veiligheidshalve (of om de door jou veronderstelde suggestie te wekken) - geen gegevens van die Z toont, al dan niet voorzien van foutmelding.
Dat is goed gebruik bij caching, en standaard in browsers en bijv. bij de checks die Windows doet bij opstarten - o.a. of er wijzigingen in op de PC gecachte rootcertificaten moeten worden doorgevoerd.
Dat is goed gebruik bij caching, en standaard in browsers en bijv. bij de checks die Windows doet bij opstarten - o.a. of er wijzigingen in op de PC gecachte rootcertificaten moeten worden doorgevoerd.
Of lees je eens in waarom de een cache van een browser, ook voor mogelijk wijzigende informatie, niet zinloos is.
Zucht
Aanvulling 14:37: met dank aan Anoniem van 11:38 die dit ook prima verwoordt.
11-04-2025, 16:53 door
Anoniem
Misschien interessant: https://www.rijksoverheid.nl/onderwerpen/digitale-gegevens-in-de-zorg/vraag-en-antwoord/waar-kan-ik-een-persoonlijke-gezondheidsomgeving-pgo-voor-gebruiken
Ik lees daar ondermeer:
Nu is het altijd de vraag wat iemand zal doen met de informatie die je o.a. bijv. hierbij met een IT-dienstverlener deelt.
Als je niemand vertrouwt, kan je nooit "plain" informatie met iemand delen,
maar dan kan men je dus ook niet van dienst zijn. (dit is soms een dilemma )
In geval van gevoelige informatie kan het wel eens heel terecht zijn om maar geen informatie te delen.
Soms is ook bepaalde informatie gevoeliger dan je zelf op het eerste gezicht misschien zou denken
Een bekende manier om het "redelijk veilig" te maken, is encrypted opslag waar je zelf alleen toegang toe hebt
met een betrouwbare inlogmethode.
Ik krijg ook enigszins de indruk dat PGO vermoedelijk zo zal werken: wat er op servers van IT-bedrijven terecht komt
zal naar alle waarschijnlijkheid encrypted data zijn, zodat niemand van het IT-bedrijf iets met die informatie kan.
Het lijkt mij in ieder geval logisch dat het zo zou moeten.
Overigens is het soms wél handig om informatie te delen, bijv. met een arts,
of anders wordt het lastig om goed en effectief te worden geholpen.
(ik herinner me mijn nickname niet meer)
Ik lees daar ondermeer:
Veilig en betrouwbaar met uw gegevens omgaan
Uw gegevens zijn veilig in een PGO dat het MedMij-label heeft. Dat label staat voor de afspraken die zijn gemaakt over het veilig en betrouwbaar uitwisselen van gegevens. Het zijn eigenlijk de spelregels waaraan organisaties moeten voldoen om gegevens veilig uit te wisselen en te zorgen dat uw privacy is beschermd.
Zo is bijvoorbeeld afgesproken dat u inlogt met de DigiD app waarmee u de eenmalige ID-check heeft gedaan.
Altijd toegang tot uw gegevens
Een PGO is een soort digitale kluis, waarvan alleen u de sleutel heeft. Alleen u kunt in uw PGO, niemand anders.
En u bepaalt zelf of u uw gegevens wilt delen en met wie. En deze gegevens blijven levenslang van u.
Zodat u ook jaren later nog eens terug kunt kijken en niks kwijtraakt als u wisselt van zorgverlener.
Uw gegevens zijn veilig in een PGO dat het MedMij-label heeft. Dat label staat voor de afspraken die zijn gemaakt over het veilig en betrouwbaar uitwisselen van gegevens. Het zijn eigenlijk de spelregels waaraan organisaties moeten voldoen om gegevens veilig uit te wisselen en te zorgen dat uw privacy is beschermd.
Zo is bijvoorbeeld afgesproken dat u inlogt met de DigiD app waarmee u de eenmalige ID-check heeft gedaan.
Altijd toegang tot uw gegevens
Een PGO is een soort digitale kluis, waarvan alleen u de sleutel heeft. Alleen u kunt in uw PGO, niemand anders.
En u bepaalt zelf of u uw gegevens wilt delen en met wie. En deze gegevens blijven levenslang van u.
Zodat u ook jaren later nog eens terug kunt kijken en niks kwijtraakt als u wisselt van zorgverlener.
Nu is het altijd de vraag wat iemand zal doen met de informatie die je o.a. bijv. hierbij met een IT-dienstverlener deelt.
Als je niemand vertrouwt, kan je nooit "plain" informatie met iemand delen,
maar dan kan men je dus ook niet van dienst zijn. (dit is soms een dilemma )
In geval van gevoelige informatie kan het wel eens heel terecht zijn om maar geen informatie te delen.
Soms is ook bepaalde informatie gevoeliger dan je zelf op het eerste gezicht misschien zou denken
Een bekende manier om het "redelijk veilig" te maken, is encrypted opslag waar je zelf alleen toegang toe hebt
met een betrouwbare inlogmethode.
Ik krijg ook enigszins de indruk dat PGO vermoedelijk zo zal werken: wat er op servers van IT-bedrijven terecht komt
zal naar alle waarschijnlijkheid encrypted data zijn, zodat niemand van het IT-bedrijf iets met die informatie kan.
Het lijkt mij in ieder geval logisch dat het zo zou moeten.
Overigens is het soms wél handig om informatie te delen, bijv. met een arts,
of anders wordt het lastig om goed en effectief te worden geholpen.
(ik herinner me mijn nickname niet meer)
Gisteren, 14:33 door
Erik van Straten
Door Anoniem: Misschien interessant: https://www.rijksoverheid.nl/onderwerpen/digitale-gegevens-in-de-zorg/vraag-en-antwoord/waar-kan-ik-een-persoonlijke-gezondheidsomgeving-pgo-voor-gebruiken
[...]
(ik herinner me mijn nickname niet meer)
Gelukkig heb ik een beter geheugen.[...]
(ik herinner me mijn nickname niet meer)
Ik herinner mij dat overheidsinformatie over ICT-voorzieningen, aangeboden of gestimuleerd door de overheid (waaronder CoronaMelder en CoronaCheck), altijd volstrekt eenzijdige propaganda was - als er niet glashard in gelogen werd.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Information Security Officer Operationele Techniek (ISO)
Heb jij kennis van procesautomatisering en interesse in security en informatiebeveiliging? Solliciteer dan op de functie van (aankomend) Information Security Officer bij Hoogheemraadschap Hollands Noorder-kwartier in Heerhugowaard. Als ISO Opera-tionele techniek draag jij bij aan de veiligheid van onze informatie en systemen.
Cybersecurity Trainer / Full Stack Developer
bij Certified Secure
Ben je toe aan een nieuwe nieuwe job waarmee je het verschil maakt? Wil jij je security kennis graag delen en hands-on laten zien hoe cybersecurity in de praktijk echt werkt? Werk je net als wij graag samen met enthousiaste en gedreven collega's? Bij ons geen bureaucratie maar open communicatie en een werkomgeving gericht op samenwerking.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
