<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments for Jaap-Henk Hoepman - on security, privacy and...</title>
	<atom:link href="http://blog.xot.nl/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.xot.nl</link>
	<description>On security, privacy and (occasionally) other stuff</description>
	<lastBuildDate>Sun, 22 Jan 2012 16:26:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>Comment on Discussie over gebruik BSN is een achterhoedegevecht. by Vrij gebruik van BSN onafwendbaar. Leg daarom koppelen bestanden aan banden. &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;</title>
		<link>http://blog.xot.nl/2011/12/01/discussie-over-gebruik-bsn-is-een-achterhoedegevecht/#comment-445</link>
		<dc:creator><![CDATA[Vrij gebruik van BSN onafwendbaar. Leg daarom koppelen bestanden aan banden. &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;]]></dc:creator>
		<pubDate>Sun, 22 Jan 2012 16:26:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=378#comment-445</guid>
		<description><![CDATA[[...] meer (niet publieke) zaken gebruikt. Discussie over het beperkt gebruik van BSN is dus echt een achterhoedegevecht. De privacy beschermde dat toch al niet meer. Daar hebben we andere regels voor nodig, die het [...]]]></description>
		<content:encoded><![CDATA[<p>[...] meer (niet publieke) zaken gebruikt. Discussie over het beperkt gebruik van BSN is dus echt een achterhoedegevecht. De privacy beschermde dat toch al niet meer. Daar hebben we andere regels voor nodig, die het [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on @MIGO-BORAS: met zo&#8217;n vriend heb je geen vijand meer nodig&#8230; by Jaap-Henk</title>
		<link>http://blog.xot.nl/2012/01/04/migo-boras-met-zon-vriend-heb-je-geen-vijand-meer-nodig/#comment-441</link>
		<dc:creator><![CDATA[Jaap-Henk]]></dc:creator>
		<pubDate>Mon, 09 Jan 2012 19:35:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=384#comment-441</guid>
		<description><![CDATA[Het gaat niet eens zozeer om het ontwerp van @MIGO-BORAS zelf (alhoewel de grote mate van parametrisering van het systeem me zorgen baart), als wel om de vraag waar het systeem voor wordt ingezet. Er is een groot verschil tussen het toepassen van zo&#039;n systeem voor een beperkt doel als het handhaven van Vreemdelingenwet, en het toepassen op alle aspecten van het handhaven van de veiligheid (en het daarmee als een centraal onderdeel van de totale informatiepositie van de Koninklijke Marechaussee positioneren). Bij zo&#039;n positionering hoort wat mij betreft ook de afweging of het invoeren van een dergelijk middel redelijk is, gezien de privacy impact die het toepassen van dit systeem ook heeft. Niet iedere techniek die onze wereld veiliger kan maken is wenselijk.

Daarnaast kan de gelijktijdig aangekondigde ANPR wetgeving (4 weken opslag) alle privacy beschermende aspecten van @MIGO-BORAS ongedaan maken.]]></description>
		<content:encoded><![CDATA[<p>Het gaat niet eens zozeer om het ontwerp van @MIGO-BORAS zelf (alhoewel de grote mate van parametrisering van het systeem me zorgen baart), als wel om de vraag waar het systeem voor wordt ingezet. Er is een groot verschil tussen het toepassen van zo&#8217;n systeem voor een beperkt doel als het handhaven van Vreemdelingenwet, en het toepassen op alle aspecten van het handhaven van de veiligheid (en het daarmee als een centraal onderdeel van de totale informatiepositie van de Koninklijke Marechaussee positioneren). Bij zo&#8217;n positionering hoort wat mij betreft ook de afweging of het invoeren van een dergelijk middel redelijk is, gezien de privacy impact die het toepassen van dit systeem ook heeft. Niet iedere techniek die onze wereld veiliger kan maken is wenselijk.</p>
<p>Daarnaast kan de gelijktijdig aangekondigde ANPR wetgeving (4 weken opslag) alle privacy beschermende aspecten van @MIGO-BORAS ongedaan maken.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on @MIGO-BORAS: met zo&#8217;n vriend heb je geen vijand meer nodig&#8230; by Gerard Spin</title>
		<link>http://blog.xot.nl/2012/01/04/migo-boras-met-zon-vriend-heb-je-geen-vijand-meer-nodig/#comment-440</link>
		<dc:creator><![CDATA[Gerard Spin]]></dc:creator>
		<pubDate>Mon, 09 Jan 2012 10:25:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=384#comment-440</guid>
		<description><![CDATA[@MIGO BORAS is een mooi project. Als fabrikant van kentekenherkenning systemen hebben we in de marktverkenning fase meegewerkt aan @MIGO BORAS. Er wordt hier een voorbeeld gesteld hoe je correct met kenteken gegevens kunt omgaan omdat er een zogenaamde &#039;fingerprint&#039; wordt gemaakt van een voertuig met kenteken Hiervan kunnen vele andere partijen die all onze ID&#039;s (pasjes, IP adressen, gegevens etc.) in beheer hebben nog wat van leren en een voorbeeld aan nemen. Ook social media sites en zoekmachines dus. We moeten kentekenherkenning niet koppelen aan &#039;flitspaal ervaringen&#039; maar het zien als een techniek die onze wereld o.a. veiliger kan maken.]]></description>
		<content:encoded><![CDATA[<p>@MIGO BORAS is een mooi project. Als fabrikant van kentekenherkenning systemen hebben we in de marktverkenning fase meegewerkt aan @MIGO BORAS. Er wordt hier een voorbeeld gesteld hoe je correct met kenteken gegevens kunt omgaan omdat er een zogenaamde &#8216;fingerprint&#8217; wordt gemaakt van een voertuig met kenteken Hiervan kunnen vele andere partijen die all onze ID&#8217;s (pasjes, IP adressen, gegevens etc.) in beheer hebben nog wat van leren en een voorbeeld aan nemen. Ook social media sites en zoekmachines dus. We moeten kentekenherkenning niet koppelen aan &#8216;flitspaal ervaringen&#8217; maar het zien als een techniek die onze wereld o.a. veiliger kan maken.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Een veilig en privacy-vriendelijk EPD. Kan dat? by Bèr Kesses</title>
		<link>http://blog.xot.nl/2011/11/15/een-veilig-en-privacy-vriendelijk-epd-kan-dat/#comment-391</link>
		<dc:creator><![CDATA[Bèr Kesses]]></dc:creator>
		<pubDate>Fri, 18 Nov 2011 16:39:01 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=373#comment-391</guid>
		<description><![CDATA[Ik denk dat we -heel vooruitstrevend- ook eens kunnen gaan nadenken aan een P2P architectuur. Waarbij een redelijk complex netwerk opgezet wordt om data uit te wisselen, maar de data altijd decentraal is opgeslagen. Om te beginnen zou het &quot;gewoon thuis op mijn PC&quot; kunnen staan. Naast mijn belastingadministratie en de foto&#039;s van mijn katten. Maar de eigenaar (ik) kan ook kiezen het elders op te slaan, bij leveranciers van &quot;EPD-hosting-diensten&quot;, met bijvoorbeeld web-based frontends en dergelijke erbij. 

Het EPD (epd.dat) van Anna is opgeslagen op de PC van Anna. Anna vertrouwt niemand behalve zichzelf.
Het EPD van Bert is opgeslagen bij de &quot;online EPD dienst&quot; van zijn verzekeraar. Bert vertrouwt zijn verzekeraar.

Wanneer de huisarts, Henry, van Anna haar EPD wil inzien, stuurt Henry een read-request naar Anna. Anna kan deze goed- of afkeuren. Henry moet een key meesturen om te bewijzen dat hij Henry is. 
Huisarts Henry kan ook Update (willekeurige wijzigingen in het EPD), of Append (nieuwe records toevoegen) requests sturen. 

Wanneer onderzoeker Otto een read-request stuurt, kan Anna dat eenvoudigweg negeren, weigeren of blokkeren. Of toestaan tot een deel van de data (zie verderop).

Voor Bert gaan diezelfde requests niet naar zijn thuisgeïnstalleerde client, maar naar een speciale, grote, &quot;bulk&quot; client gehost bij de verzekeraar. Deze grant, blocked of denied de requests voor Bert.

Een EPD kent &quot;views&quot;. Views, zijn door de eigenaar ingestelde toegangsprofielen. Zou zou ieder EPD standaard een &quot;public&quot; view kunnen hebben. Deze data is voor jan-en-alleman beschikbaar. Zal vooral dienst doen voor &quot;discovery&quot;, ofwel: waar kunnen we een specifiek EPD nu weer vinden. 

Maar ook een view &quot;emergency&quot;, die heel beperkte informatie vrijgeeft over bloedgroepen, belangrijke waarschuwingen (diabeet, allergie etc). 

En views die bijvoorbeeld zeer beperkte toegang geven tot bepaalde data; stel dat Bert wel wil deelnemen aan een onderzoek naar eiwitallergiën, dan geeft hij enkel zijn allergiedossier &quot;view&quot; aan de onderzoeker. 

Bijgaand kan Anna de &quot;grant&quot; permissie (rechten om anderen rechten te geven) ook doorgeven aan derden. Bijvoorbeeld zou zij Henry, haar huisarts grant-permissies geven op haar &quot;emergency&quot;.

Een onderliggende technologie hiervoor zou bijvoorbeeld couchDB kunnen zijn.

Uiteraard ontbreekt hier nog veel (zoals GUIs, backups, beveiliging etceteras). Maar in elk geval zie ik veel kansen in een platte, distributed set-up. Waarin we allemaal volledige eigenaar blijven over onze data (en dus ook kunnen kiezen(!) deze data bij derden onder te brengen). Dit als tegenhanger van de standaard-denkwijze dat dit soort projecten altijd centraal en hiërarchisch opgezet moeten worden.]]></description>
		<content:encoded><![CDATA[<p>Ik denk dat we -heel vooruitstrevend- ook eens kunnen gaan nadenken aan een P2P architectuur. Waarbij een redelijk complex netwerk opgezet wordt om data uit te wisselen, maar de data altijd decentraal is opgeslagen. Om te beginnen zou het &#8220;gewoon thuis op mijn PC&#8221; kunnen staan. Naast mijn belastingadministratie en de foto&#8217;s van mijn katten. Maar de eigenaar (ik) kan ook kiezen het elders op te slaan, bij leveranciers van &#8220;EPD-hosting-diensten&#8221;, met bijvoorbeeld web-based frontends en dergelijke erbij. </p>
<p>Het EPD (epd.dat) van Anna is opgeslagen op de PC van Anna. Anna vertrouwt niemand behalve zichzelf.<br />
Het EPD van Bert is opgeslagen bij de &#8220;online EPD dienst&#8221; van zijn verzekeraar. Bert vertrouwt zijn verzekeraar.</p>
<p>Wanneer de huisarts, Henry, van Anna haar EPD wil inzien, stuurt Henry een read-request naar Anna. Anna kan deze goed- of afkeuren. Henry moet een key meesturen om te bewijzen dat hij Henry is.<br />
Huisarts Henry kan ook Update (willekeurige wijzigingen in het EPD), of Append (nieuwe records toevoegen) requests sturen. </p>
<p>Wanneer onderzoeker Otto een read-request stuurt, kan Anna dat eenvoudigweg negeren, weigeren of blokkeren. Of toestaan tot een deel van de data (zie verderop).</p>
<p>Voor Bert gaan diezelfde requests niet naar zijn thuisgeïnstalleerde client, maar naar een speciale, grote, &#8220;bulk&#8221; client gehost bij de verzekeraar. Deze grant, blocked of denied de requests voor Bert.</p>
<p>Een EPD kent &#8220;views&#8221;. Views, zijn door de eigenaar ingestelde toegangsprofielen. Zou zou ieder EPD standaard een &#8220;public&#8221; view kunnen hebben. Deze data is voor jan-en-alleman beschikbaar. Zal vooral dienst doen voor &#8220;discovery&#8221;, ofwel: waar kunnen we een specifiek EPD nu weer vinden. </p>
<p>Maar ook een view &#8220;emergency&#8221;, die heel beperkte informatie vrijgeeft over bloedgroepen, belangrijke waarschuwingen (diabeet, allergie etc). </p>
<p>En views die bijvoorbeeld zeer beperkte toegang geven tot bepaalde data; stel dat Bert wel wil deelnemen aan een onderzoek naar eiwitallergiën, dan geeft hij enkel zijn allergiedossier &#8220;view&#8221; aan de onderzoeker. </p>
<p>Bijgaand kan Anna de &#8220;grant&#8221; permissie (rechten om anderen rechten te geven) ook doorgeven aan derden. Bijvoorbeeld zou zij Henry, haar huisarts grant-permissies geven op haar &#8220;emergency&#8221;.</p>
<p>Een onderliggende technologie hiervoor zou bijvoorbeeld couchDB kunnen zijn.</p>
<p>Uiteraard ontbreekt hier nog veel (zoals GUIs, backups, beveiliging etceteras). Maar in elk geval zie ik veel kansen in een platte, distributed set-up. Waarin we allemaal volledige eigenaar blijven over onze data (en dus ook kunnen kiezen(!) deze data bij derden onder te brengen). Dit als tegenhanger van de standaard-denkwijze dat dit soort projecten altijd centraal en hiërarchisch opgezet moeten worden.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Een veilig en privacy-vriendelijk EPD. Kan dat? by Jaap-Henk</title>
		<link>http://blog.xot.nl/2011/11/15/een-veilig-en-privacy-vriendelijk-epd-kan-dat/#comment-390</link>
		<dc:creator><![CDATA[Jaap-Henk]]></dc:creator>
		<pubDate>Thu, 17 Nov 2011 10:29:46 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=373#comment-390</guid>
		<description><![CDATA[Dit doel werd genoemd tijdens de ronde tafel discussie. Dit is misschien geen expliciet geformuleerd doel, maar wel een achterliggende motivatie voor zorgverzekeraars, ziekenhuizen, en de farmaceutische industrie om te streven naar een EPD.]]></description>
		<content:encoded><![CDATA[<p>Dit doel werd genoemd tijdens de ronde tafel discussie. Dit is misschien geen expliciet geformuleerd doel, maar wel een achterliggende motivatie voor zorgverzekeraars, ziekenhuizen, en de farmaceutische industrie om te streven naar een EPD.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Een veilig en privacy-vriendelijk EPD. Kan dat? by Bas</title>
		<link>http://blog.xot.nl/2011/11/15/een-veilig-en-privacy-vriendelijk-epd-kan-dat/#comment-389</link>
		<dc:creator><![CDATA[Bas]]></dc:creator>
		<pubDate>Thu, 17 Nov 2011 09:27:51 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=373#comment-389</guid>
		<description><![CDATA[&quot;Minder bekend is dat het EPD ook als doel heeft om als informatiebron te dienen voor allerlei onderzoeken van zorgverzekeraars, ziekenhuizen, en de farmaceutische industrie.&quot;

Beste Jaap-Henk, kun je aangeven wat je bron is voor deze zin? In het afgewezen wetsvoorstel EPD stond dat het verboden is voor anderen dan de behandelaar(s) om toegang te krijgen tot medische informatie (zorgverzekeraars worden expliciet genoemd in artikel 13ha van de wet). http://www.eerstekamer.nl/wetsvoorstel/31466_elektronisch]]></description>
		<content:encoded><![CDATA[<p>&#8220;Minder bekend is dat het EPD ook als doel heeft om als informatiebron te dienen voor allerlei onderzoeken van zorgverzekeraars, ziekenhuizen, en de farmaceutische industrie.&#8221;</p>
<p>Beste Jaap-Henk, kun je aangeven wat je bron is voor deze zin? In het afgewezen wetsvoorstel EPD stond dat het verboden is voor anderen dan de behandelaar(s) om toegang te krijgen tot medische informatie (zorgverzekeraars worden expliciet genoemd in artikel 13ha van de wet). <a href="http://www.eerstekamer.nl/wetsvoorstel/31466_elektronisch" rel="nofollow">http://www.eerstekamer.nl/wetsvoorstel/31466_elektronisch</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Identity cards should not be used to store anonymous credentials by On using identity cards to store anonymous credentials. &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;</title>
		<link>http://blog.xot.nl/2011/06/09/identity-cards-should-not-be-used-to-store-anonymous-credentials/#comment-387</link>
		<dc:creator><![CDATA[On using identity cards to store anonymous credentials. &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;]]></dc:creator>
		<pubDate>Wed, 16 Nov 2011 22:17:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=328#comment-387</guid>
		<description><![CDATA[[...] a previous blog post I argued that identity cards should not be used to store anonymous credentials. The reason being that users may not believe that a card that is used to identify them in one [...]]]></description>
		<content:encoded><![CDATA[<p>[...] a previous blog post I argued that identity cards should not be used to store anonymous credentials. The reason being that users may not believe that a card that is used to identify them in one [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Future of Authenticating Websites (FAWN) &#8211; 1 by The Future of Authenticating Websites (FAWN) &#8211; 2 &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;</title>
		<link>http://blog.xot.nl/2011/10/06/the-future-of-authenticating-websites-fawn-1/#comment-363</link>
		<dc:creator><![CDATA[The Future of Authenticating Websites (FAWN) &#8211; 2 &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;]]></dc:creator>
		<pubDate>Mon, 24 Oct 2011 15:29:52 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=359#comment-363</guid>
		<description><![CDATA[[...] the discussion at the Radboud University on the future of authenticating websites, I lead a similar discussion at [...]]]></description>
		<content:encoded><![CDATA[<p>[...] the discussion at the Radboud University on the future of authenticating websites, I lead a similar discussion at [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on The Future of Authenticating Websites (FAWN) &#8211; 1 by Jaap-Henk</title>
		<link>http://blog.xot.nl/2011/10/06/the-future-of-authenticating-websites-fawn-1/#comment-347</link>
		<dc:creator><![CDATA[Jaap-Henk]]></dc:creator>
		<pubDate>Thu, 06 Oct 2011 19:45:48 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=359#comment-347</guid>
		<description><![CDATA[Manually editing a list of CA&#039;s is not something an average user will (or even should) do. If he deletes the wrong one, he may end up with loads of warnings about untrusted sites (with whom nothing is wrong). So: not user centric at all, I&#039;m afraid.

I agree that key pinning (or hard-coding certificates) is not a proper long term solution. However, it is a quick fix that helps protect the major websites (and thus the majority of Internet users).


P.S.: Thanks for spotting the dangling pointer! Fixed now. And thanks for the link to the movie. I&#039;ll check it out later, once I&#039;m off the train and back to a normal bandwidth connection...]]></description>
		<content:encoded><![CDATA[<p>Manually editing a list of CA&#8217;s is not something an average user will (or even should) do. If he deletes the wrong one, he may end up with loads of warnings about untrusted sites (with whom nothing is wrong). So: not user centric at all, I&#8217;m afraid.</p>
<p>I agree that key pinning (or hard-coding certificates) is not a proper long term solution. However, it is a quick fix that helps protect the major websites (and thus the majority of Internet users).</p>
<p>P.S.: Thanks for spotting the dangling pointer! Fixed now. And thanks for the link to the movie. I&#8217;ll check it out later, once I&#8217;m off the train and back to a normal bandwidth connection&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Het Diginotar incident: het certificeringsmodel van het Internet moet op de schop. by The Future of Authenticating Websites (FAWN) &#8211; 1 &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;</title>
		<link>http://blog.xot.nl/2011/09/01/het-diginotar-incident-het-certificeringsmodel-van-het-internet-moet-op-de-schop/#comment-346</link>
		<dc:creator><![CDATA[The Future of Authenticating Websites (FAWN) &#8211; 1 &#171; Jaap-Henk Hoepman &#8211; on security, privacy and&#8230;]]></dc:creator>
		<pubDate>Thu, 06 Oct 2011 19:41:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xot.nl/?p=350#comment-346</guid>
		<description><![CDATA[[...] will not elaborate on other approaches I discussed earlier (like using DNSSEC with DANE, Perspectives or [...]]]></description>
		<content:encoded><![CDATA[<p>[...] will not elaborate on other approaches I discussed earlier (like using DNSSEC with DANE, Perspectives or [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

