On Aug 1, 2013, at 10:07 PM, Ryan Lane <rl...@wikimedia.org> wrote:
> Also,
> our resources are delivered from a number of urls (upload, bits, text)
> making it easier to identify resources. Even with padding you can take the
> relative size of resources being delivered, and the order of those sizes
> and get a pretty good idea of the article being viewed. If there's enough
> data you may be able to identify multiple articles and see if the
> subsequent article is a link from the previous article, making guesses more
> accurate. It only takes a single accurate guess for an edit to identify an
> editor and see their entire edit history.
>
> Proper support of pipelining in browsers or multiplexing in protocols like
> SPDY would help this situation. There's probably a number of things we can
> do to improve the situation without pipelining or newer protocols, and
> we'll likely put some effort into this front. I think this takes priority
> over PFS as PFS isn't helpful if decryption isn't necessary to track
> browsing habits.
This needs some proper crypto expert vetting, but...
It would be trivial (both in effort and impact on customer bandwidth) to pad
everything to a 1k boundary on https transmission once we get there. A
variable length non-significant header field can be used. Forcing such size
counts into very large bins will degrade fingerprinting significantly.
It would also not be much more effort or customer impact to pad to the next
larger 1k size for a random large fraction of transmissions. One could imagine
a user setting where one could opt in or out of that, for example, and perhaps
a set of relative inflation scheme sizes one could choose from (10% inflated,
25% inflated, 50%, 50% plus 10% get 1-5 more k of padding, ...).
Even the slightest of these options (under https everywhere) starts to give
plausible deniability to someone's browsing; the greater ones would make
fingerprinting quite painful, though running a statistical exercise of such
options to see how hard it would make it seems useful to understand the
effects...
The question is, what is the point of this? Provide very strong user
obfuscation? Provide at least minimal individual evidentiary obfuscation from
the level of what a US court (for example) might consider scientifically
reliable, to block use of that history in trials (even if educated guesses
still might be made by law enforcement as to the articles)?
Countermeasures are responses to attain specific goals. What are the goals
people care about for such a program, and what are the Foundation willing to
consider worth supporting with bandwidth $$ or programmer time? How do we come
up with a list of possible goals and prioritize amongst them in both a
technical and policy/goals sense?
I believe that PFS will come out higher here as it's cost is really only CPU
crunchies and already existent software settings to choose from, and its
benefits to long term total obscurability are significant if done right.
No quantity of countermeasures beat inside info, and out-of-band compromise of
our main keys ends up being attractive enough as the only logical attack once
we start down this road at all past HTTPS-everywhere. One time key compromise
is far more likely than realtime compromise of PFS keys as they rotate, though
even that is possible given sufficiently motivated successful stealthy
subversion. The credible ability to in the end be confident that's not
happening is arguably the long term ceiling for how high we can realistically
go with countermeasures, and contains operational security and intrusion
detection features as its primary limits rather than in-band behavior.
At some point the ops team would need a security team, an IDS team, and a
counterintelligence team to watch the other teams, and I don't know if the
Foundation cares that much or would find operating that way to be a more
comfortable moral and practical stance...
George William Herbert
Sent from my iPhone
_______________________________________________
Wikimedia-l mailing list
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
