<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Understanding the Sparse Vector Technique for Differential Privacy · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/1603.01699/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/1603.01699/feed.xml" rel="self" type="application/rss+xml" /><item><title>Understanding the Sparse Vector Technique for Differential Privacy — mentioned by majos</title><link>https://news.ycombinator.com/item?id=20514127</link><guid isPermaLink="false">urn:hackerpapers:mention:1603.01699:20514127</guid><pubDate>Wed, 24 Jul 2019 11:40:12 GMT</pubDate><description>&lt;p&gt;&amp;gt; Unfortunately, Differential Privacy proofs can be used to justify applications which turn out to leak privacy when the proofs are shown to be incorrect after the fact, when the data is already out there and the damage already done. You are right that some differential privacy proofs have later been found to be wrong. For example, there is an entire paper about bugs in initial versions of the sparse vector technique [1]. However, I imagine this will evolve the way cryptographic security has evolved: at some point, enough experts have examined algorithm X to be confident about its…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/1603.01699/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>cs.CR</category></item></channel></rss>
