<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Privacy on Oliseus Blog</title><link>https://oliseus.com/tags/privacy/</link><description>Recent content in Privacy on Oliseus Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>simon.bernbeck@gmail.com (Simon Bernbeck)</managingEditor><webMaster>simon.bernbeck@gmail.com (Simon Bernbeck)</webMaster><copyright>© 2024 Simon Bernbeck. All rights reserved.</copyright><lastBuildDate>Mon, 05 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://oliseus.com/tags/privacy/index.xml" rel="self" type="application/rss+xml"/><item><title>PrivDev: What a Code Scanner Can Tell Us About Privacy</title><link>https://oliseus.com/digital-odyssey/posts/privdev-privacy-research-introduction/</link><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><author>simon.bernbeck@gmail.com (Simon Bernbeck)</author><guid>https://oliseus.com/digital-odyssey/posts/privdev-privacy-research-introduction/</guid><description>&lt;p>A developer can search a codebase for personal data and still miss the question that matters: what should the team do with the finding? A scanner may report an email address or a storage pattern. It cannot see the full purpose of processing, the people involved, every technical safeguard, or the organisation&amp;rsquo;s legal decisions. PrivDev began with that gap between a technical observation and a responsible privacy review.&lt;/p>
&lt;p>PrivDev is my research project at PUC-Rio&amp;rsquo;s AISE Laboratory. Its working idea is a &lt;strong>security-to-privacy bridge&lt;/strong>: preserve what a scanner actually observed, connect it to a shared vocabulary, and make the reasoning available for inspection. I want developers to receive a useful starting point while leaving decisions that require context with the people who have it.&lt;/p></description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://oliseus.com/digital-odyssey/posts/privdev-privacy-research-introduction/featured.svg"/></item><item><title>PrivDev: Why a Cryptography Finding Needs Context</title><link>https://oliseus.com/digital-odyssey/posts/privdev-cryptography-and-context/</link><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><author>simon.bernbeck@gmail.com (Simon Bernbeck)</author><guid>https://oliseus.com/digital-odyssey/posts/privdev-cryptography-and-context/</guid><description>&lt;p>Cryptography often appears in privacy discussions as a single checkbox: encrypted or not encrypted. Software findings are rarely that complete. A scanner can identify a suspicious storage path or a call to an unsafe primitive, but it does not automatically know what data is involved, who can read it, which controls exist outside the analysed code, or whether the data needed to be stored in the first place.&lt;/p>
&lt;p>That gap is a useful case for &lt;a
href="../privdev-privacy-research-introduction/">PrivDev&lt;/a>, my research on connecting technical findings to privacy concepts. The project&amp;rsquo;s implemented first layer maps scanner data-type labels to a common vocabulary. A later research question asks how findings about software weaknesses could support developer guidance without turning a technical clue into a legal verdict. Cryptography exposes why this distinction matters.&lt;/p></description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://oliseus.com/digital-odyssey/posts/privdev-cryptography-and-context/featured.svg"/></item><item><title>PrivDev: Turning Static-Analysis Findings into Privacy Knowledge</title><link>https://oliseus.com/digital-odyssey/posts/privdev-static-analysis-to-privacy/</link><pubDate>Wed, 29 Jul 2026 00:00:00 +0000</pubDate><author>simon.bernbeck@gmail.com (Simon Bernbeck)</author><guid>https://oliseus.com/digital-odyssey/posts/privdev-static-analysis-to-privacy/</guid><description>&lt;p>The first PrivDev study connects data-type labels from a code scanner to a privacy vocabulary. That sounds straightforward until a label is ambiguous, the vocabulary has no close match, or a graph asserts more than the scanner could know. This article records what the first implementation accomplished and what later review changed. For the wider research programme, see the &lt;a
href="../privdev-privacy-research-introduction/">PrivDev introduction&lt;/a>.&lt;/p>
&lt;h2 class="relative group">From a scanner label to a category
&lt;div id="from-a-scanner-label-to-a-category" class="anchor">&lt;/div>
&lt;span
class="absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100">
&lt;a class="group-hover:text-primary-300 dark:group-hover:text-neutral-700 !no-underline" href="#from-a-scanner-label-to-a-category" aria-label="Anchor">#&lt;/a>
&lt;/span>
&lt;/h2>
&lt;p>Bearer CLI provides the 122 input data-type labels used in this study. The pipeline relates them to personal-data categories in the &lt;a
href="https://www.w3.org/community/reports/dpvcg/CG-FINAL-pd-20240801/"
target="_blank"
>Data Privacy Vocabulary&amp;rsquo;s PD extension&lt;/a>. The output is an RDF/Turtle graph that can be queried with SPARQL. It records a proposed interpretation of each scanner label, not a description of every real processing activity in which that label might occur.&lt;/p></description></item></channel></rss>