Privacy by design was zogenaamd een argument dat de App toch zou kunnen worden ingevoerd.
Die slogan heeft natuurlijk een fop werking.
Het is het white-washen van de praktijk van inlichtingen diensten waarvan velen hebben geleerd dat het niet klopt.

Ik kan me wel voorstelen dat er intenties waren om maximaal privacy te bieden met die app.
Alleen is privacy natuurlijk geen werkwoord als in van doen / toepassen of een bijvoeglijk naamwoord als in ik ontwerp privacy vriendelijk. Privacy is een te eerbiedigen sfeer van de samenleving zelf.
Het is ook geen verbijzondering van een fase of werkwijze.
Je hoeft privacy überhaupt niet als app ontwikkelaars verder te ontwerpen door middel van apps.
Professionals weten verder dat je met F.A.S.T. tabellen ten behoeve van optuigen van een PvE sowieso niet per se toekomt tot alle aspecten van privacy - eerbiediging - borgingen zonder dat je herdefinities, afgeleiden en/of scope creep krijgt.
Dat is dus ook wat je onvermijdelijk doorvoert als je het adagium privacy by design huldigt.
Maar dat is ofwel de app nog minder werking meegeven dan het überhaupt kan hebben, danwel dat het vooral een extra stress factor en privacy inbreuk is.
Met het adagium privacy by design heb je per saldo op enig onderdeel als ontwikkelaar niet gedaan / gerealiseerd als wat er beweert wordt dat het zou bieden.
Daarvan heb ik al teveel professionele beoordeling voorbeelden bij andere prachtige software oplossingen.
Dit op basis van evaluaties die ik deed bij 2 tot 6 maanden na aanvang van de gebruiksfase.
Waarbij in gevallen variërend per software oplossing een brede schare tevreden of ontevreden gebruikersgroep was.

Backend status:

https://secure-status.coronamelder-backend.nl/

Goh. Verbazend. En zeker niemand zag het aankomen?

Struisvogelpolitiek heet dat.

Is er ook nog maar iemand die de illusie heeft dat het gebruik van een mobiele telefoon privacy proof te maken is?
Die dingen hebben allemaal phone home apps van zowel Google, Apple, FB, de fabrikant van het toestel en de appbouwers.
Daarnaast zijn er nog de providers die alle verbindingen in de gaten houden en vrij nauwkeurig weten waar je bent en met wie je contact hebt. Het mobiele platform is qua privacy zo lek als een mandje en daar gaat geen enkele app ook maar iets aan veranderen.
Het enige apparaat waarvan ik denk dat het privacy by design kan zijn is een soort van fysiek bleutooth scanner, zonder wifi of gsm zenders erin, die je los kan ophalen bij de Bruna of welk distributiepunt dan ook, zonder legitimatie, en die volledig zelfstandig werkt en waar je van de GGD website regelmatig een bestandje download die je via USB op het apparaat zet waarmee de scanner up to date blijft.
De scanner geeft dan aan of er iemand in jouw buurt is geregistreerd met een actieve Corona besmetting. Het apparaatje geeft je dan alleen een seintje dat je in de buurt bent van een actieve Corona besmetting bent zonder dat je kan zien wie dat zou kunnen zijn. Goed, als je met z'n tweeën in een een grote hal staat dan is het duidelijk wie besmet is, daar doe je weinig tegen.
De GGD weet niet wie jij bent en er zijn geen luistervinkjes die met jou meekijken waar je bent en ook weten wie je bent.
Maar ik kan me voorstellen dat het weer een apparaat is om mee te nemen hoewel zoiets niet heel groot hoeft te zijn. Vroeger had ik zo'n wifi scan apparaatje waarmee ik kon zien of er wifi in de buurt was, een apparaatje niet groter dan een sleutelhanger. Zoiets stel ik me dat de Corona scanner zou moeten zijn qua omvang.

Aha en wie zijn er dan interessant voor inlichtingendiensten? Jan, Mo en Corry van de vulploeg ?
Omdat er een blikje tegen de houdbaarheidsdatum loopt....


--Pak snel het aluhoedje uit de onderste la--

Nu on topic:

Er zijn nog wat randzaken welke moeten worden afgesproken. De app opzich zit qua privacy gedegen in elkaar.

- Waar staan de servers met data.
- Afscherming data naar derden-partijen op contract.
- Vernietiging van de gegevens na de afgesproken bewaarperiode.

Op BNR werden een aantal zaken verduidelijkt en heel eerlijk gezegd was het niet zo spannend, anders dan dat het moet worden geregeld in een contract met Google en Apple. Deze hadden nog geen antwoord gegeven op moment van bovenstaand bericht.

Het is geregeld via de AP in Ierland (wegens de hoofdkantoren van Google en Apple), NL was overigens het land met de meeste vragen inzake waarborging privacy. Ongeveer 2x zoveel als andere EU landen. De EU commissie heeft een NL bedrijf de opdracht gegeven de code en het framework te controleren.

De voorgestelde wet moet duidelijkheid geven in de bevoegdheid van de overheid(s-diensten) om problemen met de AP te voorkomen.

Even naast de nodige scepsis van veel mensen (gedeeltelijk ik zelf ook) en het gemiste momentum.

Ik vraag me af of jij wel begrijpt wat met privacy by design bedoeld wordt. Daar wordt niet mee bedoeld dat je een privacyverhogende app maakt, maar dat de app zo ontworpen is dat privacy er niet door geschonden wordt. En de implementatie moet vervolgens natuurlijk ook deugen om dat waar te maken.

Als jij inderdaad verstand hebt van software ontwikkelen hebt dan zou je moeten weten dat het achteraf toevoegen van eisen waar in het begin helemaal geen rekening mee is gehouden maar al te vaak tot problematische implementaties leidt waar veel in misgaat, omdat de toevingingen gebouwd worden op een fundament waar ze niet op passen. Privacy by design gaat precies daarover: zorg dat de privacy onderdeel is van het fundament en geen toevoeging achteraf op een fundament dat het eigenlijk niet ondersteunt.

Als je niet toekomt aan het borgen van privacy in het programma van eisen dan ben je per definitie niet bezig met privacy by design. Voor privacy by design heb je een werkwijze nodig die borgt dat je daar wel aan toekomt. De herdefinities, afgeleiden en scope creep zijn typisch symptomen van dingen bouwen op een fundament dat er niet geschikt voor is.
Nee, dat is wat je onvermijdelijk doorvoert als je het niet huldigt.


De manier van corona-tracking, zoals toegepast in de app, is op zich een mooi voorbeeld van het toepassen van privacy by design. Men genereert niet tot een persoon terug te herleiden identifiers en wisselt die uit bij ontmoetingen. Pas als iemand besmet is komen de identifiers van de laatste weken in een centrale database terecht die geen koppelingen naar personen bevat, en het herkennen van een besmettingsrisico van een persoon is niet gebaseerd op de persoonsgegevens van een besmette persoon. Dat ontwerp is het resultaat van wel in het programma van eisen opnemen dat privacy gewaarborgd wordt.

De zorg hier is of het juridisch goed dichtgetimmerd is en of alle onderdelen van de implementatie ook controleerbaar goed zijn. Apple en Google hebben een belangrijke component daarvan in hun OS'en verwerkt, en zijn daardoor perfect gepositioneerd om die identifiers stiekem toch aan persoons- en locatiegegevens te koppelen en centraal op te slaan. Implementatiefouten en beveiligingslekken kunnen derden in staat stellen om dat te doen.

Jawel, iedereen zag dat aankomen behalve voorstanders van de APP doen als of ze deze niet aan zagen komen.

De AP is juichend over de KopieID-app, die voor Android en iOS beschikbaar is.
Hiervoor is geen enkele afspraak gemaakt met Google en Apple, terwijl wel gebruik gemaakt wordt van de ingebouwde diensten van Android en iOS.

Nu is er een nieuwe app, die gebruik maakt van een nieuwe dienst in het onderliggende OS en dan moet er ineens wel van alles worden afgesproken?

Wat ik me afvraag is waarom uberhaupt Google en Apple voor de installatie van de Corona-App nodig zijn? De overheid zou de App en/of het apk bestand dat tevens is voorzien van een verificatie code simpelweg op 1 of meer overheids websites kunnen plaatsen, al dan niet voorzien van een instructie hoe te installeren.

Er van uitgaande dat de app zelf verder inderdaad helemaal niets anders dan het unieke nummer van de gebruiker zelf registreert en het unieke nummer van ieder contact direct (encrypt op basis van steeds een andere unieke sessie key) via een dataverbinding naar een centrale database (ook zonder verdere registratie van de verzender) doorstuurt dan is er verder alleen nog een eenvoudige, 1:n database nodig die elk contact (in n) na 2 weken weer verwijdert.

Daarnaast dient de app zelf aan de database te melden wanneer de houder van de app zelf is besmet, en dient periodiek (ook vanuit de app zelf) de database te worden gecontroleerd of 1 of meer van de van de eerder verstuurde unieke nummers is besmet.

Het enige dat de overheid dan nog hoeft te doen is een deal te maken met de telecom providers over het verzenden en ontvangen van de (encrypte) unieke nummers.

Op zich stelt dat niet zo heel veel voor (ook niet qua database). Ga eens uit van 1024 bits per (encrypt) uniek nummer en gemiddeld 100 contacten per iedere Nederlander (18 miljoen) per twee weken. Dan nog heb je het over hooguit ca. 230 Gigabyte per 2 weken voor heel Nederland.

Zo ingewikkeld is dit allemaal toch niet?

Misschien al eerder gevraagd en beantwoord maar toch even checken. De app werkt vooralsnog in bepaalde delen van Nederland. Hoe weet de app via de of locatiebepaling waar je bent?

Tja, je maakt de argumentatie toch echt niet helemaal af.
Doe je dat wel dan kom je op vervolg van over het geheel niet doen alsof het ergens toevoegen van iets privacy inbreuken kan herstellen.
Inherent aan wat eenmaal in het systeem komt, ook als je input of afgeleide input hanteert die je zogenaamd onherleidbaar denkt te maken, de output van het systeem houdt ALTIJD verband met de oorsprong van wat je er in stopt.
Dus ja, privacy by design is sowieso GEEN privacy borging als je met gegevens werkt die herleidbaar uniek zijn.
Intelligente middellen als maskering van identiteiten zijn in die zin processing en voegen dus niets wezenlijks toe aan het kunnen verhinderen van iemands indentiteit.
Veroorzaakt hoogstens een kleine vertraging in het vaststellen van iemands identiteit of een extra benodigde tussenstap voor de reverse engineering ervan.
Dat is dus zeker geen borging van privacy.
Precies wat je dus NIET benoemt is de bevestiging dat privacy by design een non-claim of non-resultaat is zodra je eenmaal id records / privé gegevens gaat verwerken en/of breed gaat ontsluiten.
Dus juist het complete besef van de eigen beperkingen bij het opstellen van PvE's en zaken als F.A.S.T. tabellen doet ons beseffen dat de privacy van de App zelfs op papier niet volledig geborgd is en voorlopig niet geborgd gaat worden zo lang je de enge interpretaties van privacy en borging ervan toepast.
Die enge interpretatie van privacy is volgens de verantwoordelijke minister bij het optuigen van de AP en de AVG nou juist EXPLICIET lNIET de bedoeling.
Het hanteren en controleren van privacy eisen en datgeen dat je niet goed kan definiëren als privacy eis moest volgens die minister echter wel degelijk "geen vrijbrief" worden.
Dus geen vrijbrief om met PvE's enigszins richting een schaamlap op te gaan schuiven.
"Ook niet als de AP er onbewust of onbedoeld met haar beslissingen aan bijdraagt of aan meewerkt" aldus de verantwoordelijke minister.
"Ook is privacy geen inspanning verplichting of beperkt het zich daartoe" aldus de minister.
In die zin mist je argumentatie dus deels de kern van de zaak.
Privacy-waarborgen is dus zeg maar geen werkwoord!


Een belangrijke correctie, privacy inbreuken is wat je onvermijdelijk doorvoert als je niet alle inzichten en besef van het ontwerp proces huldigt.
De makers van de App komen met hun aanpak dus NIET toe aan het opstellen van een COMPLETE eisen set voor privacy borging.
Of je nou wel of geen privacy by design principes huldigt en toepast met de juiste interpretatie die bij de meritus ervan past.
En dan weet je als het goed is ook dat er ook borging vereisten kunnen spelen die je taalkundig niet fatsoenlijk in eisen kan beschrijven en valideren maar wel degelijk moet borgen.
Het blijft daarom onvermijdelijk zo dat je privacy inbreuken mogelijk maakt en realiseert indien je de App gaat uitrollen.

De zogenaamde impliciete eisen.
De eisen die je aan de App stelt en waarvan iedereen die zich met een ontwikkel proces ook wel aanvoelt dat dat geborgd moet worden maar lastig ergens uit naar boven te halen is.
Stel dat je App 95% van alle privacy checks op orde zou hebben, maar de laatste 5% is wat weerbarstig in de app te verankeren. Als je dat dan eenmaal hebt gedaan dan moet je ook nog borgen dat de App in de interactie met de omgeving volledig de privacy eerbiedigt.
De opmerkingen vanochtend rond 10:00 uur van de AP laten zien hoe weerbarstig dat is.
Het borgen van privacy van mensen houd namelijk niet op bij enkel de interactie van de app met de Google/Apple back-end of wat ze daarin al/dan niet afspreken. Nee, bij het optuigen van de AP, de AVG en aanverwante borgingen voor privacy is namelijk gezegd dat die niet sec worden opgetuigd om als beperkte uitleg of controle te kunnen dienen.
Dan zou het volgens de verantwoordelijke minister daarbij namelijk "richting het doorwuiven van privacy inbreuken kunnen gaan en dat zou nou juist de hele doelstelling waarom die aanvullingen überhaupt worden getroffen geheel of gedeeltelijk ondermijnen of zelfs teniet doen".
Het claimen van Privacy by design is dus in staatsrechtelijke en privaatrecht zin NIET synoniem met GEEN privacy inbreuken plegen, mogelijk maken of privacy vriendelijk willen zijn. Waarbij privacy geen begrip is van wel of niet vriendelijk willen zijn.
Dat is een gegeven dat je met de App dus niet goed overeind houdt.
Bij het hanteren van Privacy by design claims in die zin ben je de boel toch echt om de tuin aan het leiden.
Mijn suggestie zou zijn, vergeet het huidige mooie container-idee als Privacy by design en verdiep jezelf in de bredere betekenis van privacy.

Zoals u weet / zou kunnen weten is het hashen / unmasken bij 1000 id's in een postcode gebied al kinderspel.
Helemaal als die 1000 id's zich in 1 winkelgebied bewegen.
De hele massa-opzet van de App maakt het dus minstens ook relevant om ook bij de fase stil te staan voordat gegevens naar een centrale database worden ontsloten.
Bovendien leunt uw betoog direct hierboven op maar 1 deel-secnario, namelijk het eenmaal in een centrale database terecht komen.
De oorsprong van de gegevens ligt daarvoor al vast in het stelsel, zodra je eenmaal 1000 of meer aantallen componenten en personen in een stelsel vastlegt.
Die komt inherent bovendrijven zodra je een combinatie van componenten uit het stelsel bekijkt.
Die oorsprong kan je bij een uitgebreider systeem nou eenmaal functioneel dus ook niet meer uitwissen.
Zie het als dat iemand een zonnebril draagt, de meeste mensen die dat doen kan je vaak toch nog voldoende herkennen.
Die principes maken de route waarlangs gegevens wel of niet bewust moeten worden ontsloten wordt daarmee voor het privacy aspect vrijwel irrelevant.
Daar moet je wel eerlijk over zijn.
Het is een zogenaamd helaasheid van dit soort dingen.
Valt met een echte brede mindset ook niet te whitewashen.
Privacy by design claimen is in deze context eigenlijk ook een contra dictio in terminis.
Al waardeer ik wel de goede bedoeling die erachter zat om dit idee te promoten.

Verder is de manier waarop je een techniek toepast bij technische oplossingen natuurlijk ook altijd van invloed.
Tegelijk kan de manier van een techniek geen privacy inbreuken ongedaan maken of vermijden die er van oorsprong in zitten of insluipen.
Ongeacht of je nou ver (door)ontwikkelde processen ervoor optuigt of niet.
Zie voor de reden de bredere verbanden van systemen die ik hierboven al toelichtte.

Nou is het juridische natuurlijk 1 van de aspecten, maar het beperkt zich niet slechts tot wat je met de app ontwikkeling doet maar zeker niet het enige dat privacy inbreuken kan veroorzaken.
Dat deze elementen de verengde uitleg is van wat je als App makers sowieso MOET borgen is logisch.
Dat is ook toegelicht door de verantwoordelijke minister en de bedoeling van de privacy waarborgen, expliciet maar ook impliciet.
Hetgeen als een nadenkertje ook bij het eerdere sub-commentaar in deze bijdrage al is opgemerkt.
Privacy is een breder dan een paar partijen en universeel iets.
Beperk de denk-oefening dus zeker niet tot wat een App maker wel/niet van een Apple en Google kan verlangen of ermee kan regelen.
Hetgeen de AP na aanvang vanochtend volgens mij ook wel tot besef is gekomen.
En anders moeten ze nog maar eens nalezen waarvoor ze wel en waarvoor NIET zijn opgericht.

Herstel: Misschien al eerder gevraagd en beantwoord maar toch even checken. De app werkt vooralsnog in bepaalde delen van Nederland. Hoe weet de app via de IP of locatiebepaling waar je bent?

Hij werkt in het hele land maar melden bij de GGD kan alleen in de testgebieden.

Heeft tot zoverre minder met dit topic te maken dan dat de AP eerder al aangaf dat de App inherent problematisch is.
Dat verandert niet doordat je opeens maar in een paar gebieden gegevens door laat zenden.
Privacy is natuurlijk niet beperkt tot heel NL minus deze 2 gebieden van Nederland.

Is de PIA / DPIA openbaar gemaakt? En zo ja, waar is die te vinden? Of minimaal gedeeld met alle leden van de 1ste en 2de kamer?

Dit is een belangrijke factor waarom het in IT land met overheden zo vaak verkeert gaat. Uitbreiding van de scope halverwege het traject. Een project ineens gebruiken als kapstok voor bijzaken.

Als het traject een complex is dan kan het zelfs met het bereiken van een 1/4 van het traject al genoeg zijn om te kunnen reconstrueren dat het in het geheel verkeerd gaat.
Dat kan je in dit geval zowel in A) brede zin als in B) iets engere zin vaststellen.

A. Het traject kan je vanuit een App overstijgende aanpak benaderen.
Waarbij naast de App diverse aanpalende zaken worden opgetuigd en output daarvan wordt ontsloten.
Dat zelfs die uitgebreidere overweging voor de scope valkuil mijn inziens geen tot weinig verschil maakt blijkt uit het volgende.

Waar zit het 1/4 punt van de scope (app / app en aanpalende acties) in het traject van de de Jonge?
Even een paar kantelmomenten met data ter reconstructie.

Als start kan je de aankondiging van de Jonge op 7-4-2020 nemen van het (overigens mislukte) hackaton weekend (18-4-2020 t/m 19-4-2020).
Voor het weekend was medio 15-4-2020 al broncode door/namens het ministerie opgetuigd.
(https://www.security.nl/posting/652536/Overheid+maakt+komend+weekend+broncode+geselecteerde+%27corona-apps%27+openbaar)
Dus mag je zeker stellen dat zeker tussen 7-4-2020 en 15-4-2020 minstens 10% van de scope al was uitgewerkt.

Een belangrijk intern omslag punt is de weken na het hackaton weekend zelf.
Toen werd naarstig besloten om naast / bovenop de hackaton uitkomsten alsnog iets op te tuigen dat feitelijk voortborduurt op de oorsprong van de scope.
(https://www.security.nl/posting/651711/Kamervragen+over+beveiligingsadvies+bluetooth+en+gebruik+contact-tracing+app)
De bevindingen over het traject wezen uit dat dit duidelijk tekort schoot.
(https://www.computable.nl/artikel/nieuws/digital-transformation/6916093/250449/corona-opsporingsapps-schieten-tekort.html)
(De weg naar een corona-app voor contactonderzoek was ‘ergens wel dapper’ maar deugde van geen kanten-https://www.volkskrant.nl/nieuws-achtergrond/de-weg-naar-een-corona-app-voor-contactonderzoek-was-ergens-wel-dapper-maar-deugde-van-geen-kanten~be3be20c/)

De premier gaf ondanks die belangrijke feedback aan (als stand-in en bliksem afleider voor de Jonge na de hackaton weekend) duidelijk door te willen met de ingeslagen weg van dit traject.
(https://www.security.nl/posting/653504/Rutte%3A+belangrijke+stap+in+ontwikkeling+van+corona-app+gezet)
Oftewel, het kabinet ging door na de 10% scope.

Echter wel met de nodige toevoegingen en dus scope uitbreidingen van het traject.
Het bewandelde traject ging door richting een ander evident kantel moment.
Dat in het traject ligt rond half juli 2020.
Toen bepaalde de Jonge namelijk "de vanaf datum" voor de volledige gebruiksfase van de app.
(https://www.security.nl/posting/664624/Kabinet+wil+coronavirus-app+CoronaMelder+op+1+september+invoeren)
"De datum vanaf" van de volledige gebruiksfase zou per 1-9-2020 ingaan.
Dat kan je alleen afkondigen als je een volwaardig uitzicht hebt op afronding van je traject.
Half juli 2020 beschouw ik daarom, kan arbitrair zijn, gemakshalve als het 3/4 - 80% moment.
In de fase werd de dichtheid van gevonden virus deeltjes per gebied erbij gesleept.
Volgens het Rivm was die dichtheid trouwens feitelijk al aan het dalen
(https://www.rivm.nl/en/news/sewage-research-decline-of-novel-coronavirus-in-netherlands)!
Hetgeen sowieso ook al bleek uit de meet-gegevens verzameld via de zogenaamde swab-tests.
Nothing new there.
Die inzichten kan in theorie de relevantie van de scope onveranderd laten,
maar de ontwikkelingen tot dan toe maken het doorgaan met scope uitbreidingen (gegevens van andere oorsprong) toch zeker minder noodzakelijk en accuut.
Waarom?
Die scope uitbreidingen zijn in die fase sowieso aantoonbaar definitief niet meer accuut.
Natuurlijk valt de noodzaak evident ook af.
Tenzij je als minister tussen 10% en 3/4 - 80% van het traject als minister niet meer kan ontkennen hoe dunnetjes de relevantie van je eigen oorspronkelijke traject werkelijk is ga je niet op dezelfde voet door (het paard achter de wagen spannen).
Er zijn dus genoeg inzichten om dus te kunnen zien dat de minister zelf ook beseft dat de scope en het traject t/m het 3/4 - 80% zonder aanvullende en uitbreiding van acties (scope uitbreidingen) daadwerkelijk als een pudding in elkaar zakt.


B) Hoeveel impact kon de scope van sec de App vanaf april 2020 nog gaan hebben?
Het antwoord daarop is een duidelijke indicatie over wat er daarna aan vooruitgang werd geboekt.
Namelijk heel weinig.
Getuige het eigen handelen en verklaringen van de Jonge waren er vanaf april 2020 diverse aanvullende maatregelen nodig.
Tussen 10 april 2020 en half juli 2020 hebben de Jonge en c.s. er namelijk van alles erbij georganiseerd (met afnemende relevantie overigens).

1) Riool data - https://www.rivm.nl/en/news/sewage-research-decline-of-novel-coronavirus-in-netherlands.
Side note:
Riool data zijn in werkelijkheid een aggregatie (op hoger abstractie niveau).
Die zijn dus per definitie geen spiegel van virus deeltjes dichtheid van een bepaald geografisch gebied in tijdspanne maar een optelsom van wat je op de plek van je meetpunten van het debiet weet te meten.
De kop van dit NOS artikel kan op dat vlak dus ook niet kloppen (https://nos.nl/artikel/2335574-corona-uitbraak-snel-te-zien-in-rioolwater-goede-spiegel-van-de-samenleving.html).

2) Telecom gegevens. - https://www.security.nl/posting/655864/De+Jonge+vraagt+telecomproviders+om+data+met+RIVM+te+delen
Waarschijnlijk kan dat ondersteunend - hoogstens een heel indirecte - indicatie bieden van hoe hetrogeen de verdeling van groepen mensen per 100.000 mensen in verloop van dagen verandert.

3) tussentijds invoering van extra projecties en modelaannames
Medio juni verkondigde Jaap van Dissel dat ze voor monitoring van het traject wel genoodzaakt waren meer projecties en model aannames in het traject toe te passen.
Als reden geeft van Dissel op dat omdat er eigenlijk geen mensen door corona in het ziekenhuis belanden waardoor een bron voor indicatie(!) van de werkelijke verspreiding graad weg valt.
Houd hierbij in het achterhoofd dat de bezettingsgraad van IC bedden in ieder geval meer zegt over de ernst van een situatie dan de algemenere informatie van alle ziekenhuisbedden bij elkaar.
In ieder geval, medio juni geeft van Dissel een verklaring af die feitelijk ook een scope aanpassing markeert.


4) Medio juli 2020 verkondigde de Jonge nog maar eens dat een vaccin nodig blijft om het traject definitief tot een einde te kunnen komen.
Tot die tijd zou Nederland afhankelijk blijven van zaken als ingebruikname van de App, aldus de Jonge zelf.


Oftewel, van de App zelf mag je volgens de Jonge zeker geen vooruitgang / afronding van het traject zelf verwachten.
De zaken die eromheen werden opgetuigd (scope wijziging / uitbreidingen) blijken secundair tot onbeduidend voor het bereiken van het hoofddoel van het traject.
Ondanks de feitelijke betekenis van de verklaringen voor de scope en voortgang denkt de Jonge vreemd genoeg toch dat het traject op dezelfde leest voortzetten vereist dat er extra zaken worden opgetuigd.
Daaronder het erbij halen van andere soorten gegevens.
Tijdens persconferenties in juni 2020 lichtte de Jonge de denksprong daarvoor toe.
Namelijk, "ALS het helpt om de gegevens centraal te ontsluiten bij de inzet tegen het virus (Corona) dan moeten we dat denk ik doen."
Hij weet op dat moment dus gewoon niet of het helpt, anders had zich daar wel meer zelfverzekerd over uitgelaten.
"Zelfs als het maar een beetje of indirect zou helpen vind ik dat we die stap moeten zetten", aldus de Jonge.
"We moeten alles op alles zetten om deze periode zo goed mogelijk door te komen" aldus de Jonge.

De officiële rapportages die Rivm her-distribueert (geforkte info van andere toeleveranciers zoals IC's) wijzen er echter op dat de gegevens nogal wat overlap hebben met wat er al bekend is.
Vervolgens verkondigt Rutte medio augustus 2020 serieus dat ze in 50% van 100% van de informatie zitten.
Hetgeen zoveel met betrekking tot die extra ontsloten informatie betekend dat die niets van het onbekende terrein heeft blootgelegd.
Een duidelijke aanwijzing dat er die periode dus daadwerkelijk weinig echte voortgang is geboekt.

Oftewel, ondanks dat er tussen april 2020 en half juli 2020 - het passeren van het 1/4 moment - van alles aan de scope werd versleuteld zijn de Jonge/Rutte per saldo niets opgeschoten.
Dit alles speelt zich af tegen een overall afname van gerapporteerde virus deeltjes dichtheden per gebied.

Hoe ernstig is dat?
In context van scope beheersing catastrofes is dat nog ernstigere mislukking dan bijvoorbeeld de totstandkoming van het Sydney Opera house. Daar werd de voortgang architect - die tussentijds met allerlei scope wijziging kwam - dermate zwaar aangerekend dat de Australische overheid op een gegevens moment zelfs een arrestatie bevel tegen de architect uitvaardigde.
In geval van de Corona App blijven de Jonge & Rutte boeken ze volgens hun eigen uitspraken netto niet vooruit komen en is er voorlopig ook geen substantiële vooruitgang te verwachten.
Het duo blijft zelfs gewoon voort zwoegen met hun eigen scope uitbreidingen in de pocket.

Dat is toch echt ultiem scope falen vanaf het 1/4 moment - grofweg ergens tussen april 2020 en half juli 2020.

Je had het kort kunnen houden met die conclusie.

Het enige wat scope betreft nog dicht bij het doel zit is de analysr van riooldata. Tijdige waarachuwing xat er wst komt aan corona zieken.

De app mag technisch werken, maar hij voldoet niet bij de eisem voor een bco verhaal. Het zit nog het dichst bij het raadplegen van de gezondheid met de olv app. Die bestond al.