<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>anonymity &#8211; Noise</title>
	<atom:link href="https://noise.getoto.net/tag/anonymity/feed/" rel="self" type="application/rss+xml" />
	<link>https://noise.getoto.net</link>
	<description>The collective thoughts of the interwebz</description>
	<lastBuildDate>Thu, 17 Jul 2025 04:19:36 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.8.2</generator>
	<item>
		<title>Security Vulnerabilities in ICEBlock</title>
		<link>https://noise.getoto.net/2025/07/17/security-vulnerabilities-in-iceblock/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Thu, 17 Jul 2025 11:06:51 +0000</pubDate>
				<category><![CDATA[anonymity]]></category>
		<category><![CDATA[ios]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[vulnerabilities]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=70479</guid>

					<description><![CDATA[<p>The ICEBlock tool has <a href="https://www.theverge.com/cyber-security/707116/iceblock-data-privacy-security-android-version">vulnerabilities</a>:</p>
<blockquote><p>The developer of ICEBlock, an iOS app for anonymously reporting sightings of US Immigration and Customs Enforcement (ICE) officials, promises that it “ensures user privacy by storing no personal data.” But that claim has come under scrutiny. ICEBlock creator Joshua Aaron has been accused of making false promises regarding user anonymity and privacy, being “misguided” about the privacy offered by iOS, and of being an Apple fanboy. The issue isn’t what ICEBlock stores. It’s about what it could accidentally reveal through its tight integration with iOS...</p></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Recovering Public Keys from Signatures</title>
		<link>https://noise.getoto.net/2024/06/20/recovering-public-keys-from-signatures/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Thu, 20 Jun 2024 11:10:53 +0000</pubDate>
				<category><![CDATA[anonymity]]></category>
		<category><![CDATA[cryptanalysis]]></category>
		<category><![CDATA[keys]]></category>
		<category><![CDATA[signatures]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=69066</guid>

					<description><![CDATA[Interesting summary of various ways to derive the public key from digitally signed files.
Normally, with a signature scheme, you have the public key and want to know whether a given signature is valid. But what if we instead have a message and a signat...]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>The Decoupling Principle</title>
		<link>https://noise.getoto.net/2022/12/07/the-decoupling-principle/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Wed, 07 Dec 2022 12:04:41 +0000</pubDate>
				<category><![CDATA[academic papers]]></category>
		<category><![CDATA[anonymity]]></category>
		<category><![CDATA[authentication]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[pseudonymity]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=66314</guid>

					<description><![CDATA[<p>This is a <a href="https://conferences.sigcomm.org/hotnets/2022/papers/hotnets22_schmitt.pdf">really interesting paper</a> that discusses what the authors call the Decoupling Principle:</p>
<blockquote><p>The idea is simple, yet previously not clearly articulated: to ensure privacy, information should be divided architecturally and institutionally such that each entity has only the information they need to perform their relevant function. Architectural decoupling entails splitting functionality for different fundamental actions in a system, such as decoupling authentication (proving who is allowed to use the network) from connectivity (establishing session state for communicating). Institutional decoupling entails splitting what information remains between non-colluding entities, such as distinct companies or network operators, or between a user and network peers. This decoupling makes service providers individually breach-proof, as they each have little or no sensitive data that can be lost to hackers. Put simply, the Decoupling Principle suggests always separating who you are from what you do...</p></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Apple’s Private Relay Is Being Blocked</title>
		<link>https://noise.getoto.net/2022/01/11/apples-private-relay-is-being-blocked/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Tue, 11 Jan 2022 15:09:37 +0000</pubDate>
				<category><![CDATA[anonymity]]></category>
		<category><![CDATA[Apple]]></category>
		<category><![CDATA[encryption]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[T-Mobile]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[vpn]]></category>
		<category><![CDATA[web privacy]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=64888</guid>

					<description><![CDATA[Some European cell phone carriers, and now T-Mobile, are blocking Apple&#8217;s Private Relay anonymous browsing feature.
This could be an interesting battle to watch.
Slashdot thread.
]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>ProtonMail Now Keeps IP Logs</title>
		<link>https://noise.getoto.net/2021/09/10/protonmail-now-keeps-ip-logs/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Fri, 10 Sep 2021 11:10:03 +0000</pubDate>
				<category><![CDATA[anonymity]]></category>
		<category><![CDATA[courts]]></category>
		<category><![CDATA[data collection]]></category>
		<category><![CDATA[Data protection]]></category>
		<category><![CDATA[e-mail]]></category>
		<category><![CDATA[Privacy]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=63656</guid>

					<description><![CDATA[<p>After being compelled by a Swiss court to monitor IP logs for a particular user, ProtonMail <a href="https://arstechnica.com/information-technology/2021/09/privacy-focused-protonmail-provided-a-users-ip-address-to-authorities/">no</a> <a href="https://www.theregister.com/2021/09/07/protonmail_hands_user_ip_address_police/">longer</a> claims that “we do not keep any IP logs.”</p>
<p>EDITED TO ADD (9/14): This seems to be more complicated. ProtonMail is <a href="https://protonvpn.com/support/no-logs-vpn/">not yet saying</a> that they keep logs. Their <a href="https://protonmail.com/privacy-policy">privacy policy</a> still states that they do not keep logs except in certain circumstances, and outlines those circumstances. And ProtonMail’s warrant canary has an <a href="https://protonmail.com/blog/transparency-report/">interesting list</a> of data orders they have received from various authorities, whether they complied, and why or why not.</p>
...]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Apple Will Offer Onion Routing for iCloud/Safari Users</title>
		<link>https://noise.getoto.net/2021/06/22/apple-will-offer-onion-routing-for-icloud-safari-users/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Tue, 22 Jun 2021 11:54:09 +0000</pubDate>
				<category><![CDATA[anonymity]]></category>
		<category><![CDATA[Apple]]></category>
		<category><![CDATA[cloud computing]]></category>
		<category><![CDATA[Safari]]></category>
		<category><![CDATA[tor]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=63391</guid>

					<description><![CDATA[<p>At this year’s Apple Worldwide Developer Conference, Apple <a href="https://developer.apple.com/videos/play/wwdc2021/10096">announced</a> <a href="https://appleinsider.com/articles/21/06/07/privacy-focused-icloud-includes-private-relay-browsing-hide-my-email-secure-homekit-cameras">something</a> called “iCloud Private Relay.” That’s basically its private version of <a href="https://appleinsider.com/articles/21/06/10/how-apple-icloud-private-relay-works">onion</a> <a href="https://www.cnet.com/news/no-apples-private-relay-is-not-a-vpn/">routing</a>, which is what Tor does.</p>
<blockquote><p>Privacy Relay is built into both the forthcoming iOS and MacOS versions, but it will only work if you’re an iCloud Plus subscriber and you have it enabled from within your iCloud settings.</p>
<p>Once it’s enabled and you open Safari to browse, Private Relay splits up two pieces of information that — when delivered to websites together as normal — could quickly identify you. Those are your IP address (who and exactly where you are) and your DNS request (the address of the website you want, in numeric form)...</p></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Oblivious DNS-over-HTTPS</title>
		<link>https://noise.getoto.net/2020/12/08/oblivious-dns-over-https/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Tue, 08 Dec 2020 21:02:08 +0000</pubDate>
				<category><![CDATA[academic papers]]></category>
		<category><![CDATA[anonymity]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[https]]></category>
		<category><![CDATA[protocols]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=60547</guid>

					<description><![CDATA[<p>This <a href="https://techcrunch.com/2020/12/08/cloudflare-and-apple-design-a-new-privacy-friendly-internet-protocol/">new protocol</a>, called Oblivious DNS-over-HTTPS (ODoH), hides the websites you visit from your ISP.</p>
<blockquote><p>Here&#8217;s how it works: ODoH wraps a layer of encryption around the DNS query and passes it through a proxy server, which acts as a go-between the internet user and the website they want to visit. Because the DNS query is encrypted, the proxy can&#8217;t see what&#8217;s inside, but acts as a shield to prevent the DNS resolver from seeing who sent the query to begin with.</p></blockquote>
<p>IETF <a href="https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-02">memo</a>.</p>
<p>The <a href="https://arxiv.org/pdf/2011.10121.pdf">paper</a>:</p>
<blockquote><p><b>Abstract:</b> The Domain Name System (DNS) is the foundation of a human-usable Internet, responding to client queries for host-names with corresponding IP addresses and records. Traditional DNS is also unencrypted, and leaks user information to network operators. Recent efforts to secure DNS using DNS over TLS (DoT) and DNS over HTTPS (DoH) havebeen gaining traction, ostensibly protecting traffic and hiding content from on-lookers. However, one of the criticisms ofDoT and DoH is brought to bear by the small number of large-scale deployments (e.g., Comcast, Google, Cloudflare): DNS resolvers can associate query contents with client identities in the form of IP addresses. Oblivious DNS over HTTPS (ODoH) safeguards against this problem. In this paper we ask what it would take to make ODoH practical? We describe ODoH, a practical DNS protocol aimed at resolving this issue by both protecting the client&#8217;s content and identity. We implement and deploy the protocol, and perform measurements to show that ODoH has comparable performance to protocols like DoH and DoT which are gaining widespread adoption,while improving client privacy, making ODoH a practical privacy enhancing replacement for the usage of DNS...</p></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
		<item>
		<title>Tracking Users on Waze</title>
		<link>https://noise.getoto.net/2020/10/29/tracking-users-on-waze/</link>
		
		<dc:creator><![CDATA[Bruce Schneier]]></dc:creator>
		<pubDate>Thu, 29 Oct 2020 14:52:55 +0000</pubDate>
				<category><![CDATA[anonymity]]></category>
		<category><![CDATA[de-anonymization]]></category>
		<category><![CDATA[Uncategorized]]></category>
		<category><![CDATA[vulnerabilities]]></category>
		<guid isPermaLink="false">https://www.schneier.com/?p=60401</guid>

					<description><![CDATA[<p>A security researcher <a href="https://threatpost.com/googles-waze-track-users/160332/">discovered</a> a <a href="https://www.malgregator.com/post/waze-how-i-tracked-your-mother/">wulnerability</a> in Waze that breaks the anonymity of users:</p>
<blockquote><p>I found out that I can visit Waze from any web browser at <a href="https://www.waze.com/livemap">waze.com/livemap</a> so I decided to check how are those driver icons implemented. What I found is that I can ask Waze API for data on a location by sending my latitude and longitude coordinates. Except the essential traffic information, Waze also sends me coordinates of other drivers who are nearby. What caught my eyes was that identification numbers (ID) associated with the icons were not changing over time. I decided to track one driver and after some time she really appeared in a different place on the same road...</p></blockquote>]]></description>
		
		
		<enclosure url="" length="0" type="" />

			</item>
	</channel>
</rss>

<!--
Performance optimized by W3 Total Cache. Learn more: https://www.boldgrid.com/w3-total-cache/

Object Caching 32/162 objects using Memcached
Page Caching using Disk: Enhanced 
Lazy Loading (feed)
Database Caching using Memcached

Served from: noise.getoto.net @ 2025-12-10 05:30:54 by W3 Total Cache
-->