is it possible to convincingly prove or disprove that daniel j. bernstein actually came up with curve25519 vs uhhh "had a vision from god"
Post
Replies:
15
Boosts:
6
[someone who develops security vulnerabilities cannot be allowed to run code for longer than 5-10 seconds on your phone. if it makes your entire phone slower i recommend exiting the entire browser app immediately. this is what side-channel attacks can look like.]
i absolutely believe cloudflare rowhammered me for a captcha on an ACM article once given that they performed three very slow reloads before my fans went off and my 64gb of RAM was swapping. i thought it was game over dude. maybe it was
clownflare really believes someone would go afk waiting for their censorship regime to decide whether to censor you. let's get one thing straight: i am timing you here.
CAP theorem (Censorship, Accountability, Plausibility): choose two
- censorship: blocking access to a resource
- accountability: the outward appearance of unfettered access
- plausibility: how likely it is for the user to assume good faith
clownflare captchas are great for surveillance alone. that's why i assumed they would just fingerprint me asynchronously, linking my frontend browser id to the backend id of my request as it propagates through cloudflare IXPs.
that's a great gig! a new spin on the old classic!
but the ACM "open access" flow is much slower than standard clownflare!
(this probably should have been a clue because tracking alone, afaiu, is almost always done async. maybe you could open a websocket and trace a few more pings with a lengthier time budget, but that looks weird)
without interpreting it yet, it's important to recognize that average time to successful entry is a signal. reliably longer wait times for X vs Y through customsflare indicates that Y is assigned a higher time budget.
clownflare (and google, and twitter, and...) frequently claims that each second waiting longer causes users to "give up" in some unspecified way. this is used to convince management types to e.g. use google AMP and kill their own website, so any relationship of that claim with the truth is entirely incidental.
in addition, this problem description quite skillfully assumes the user is on google search or other decontextualized list of results, and the user is trying to evaluate likelihood/interest.
but that's not how customsflare interstitial spinners work. the user almost always knows the document they need (e.g. looking up a DOI from ACM "open access"). the spinner blocks them. so our concept of "time budget" is not about attracting users to read our page over others. for this, we need the evil 🧢 theorem proposed above
the decision to make a document contextually or globally inaccessible.
we define this in two major forms:
- explicit: a direct request for a document via globally unique identifier fails to complete successfully within the expected time span.
- implicit: the document is removed from the results list for any or all queries.
(if a uuid is a "query", could these be said to overlap?)
fun facts about explicit censorship:
- any URI is just such a universally unique identifier
any non-success result is censorship, particularly "security" errors
a timeout policy produces yes/no/timeout and always completes under the timeout, which may often be more applicable than indefinite waiting
- however, understand that a static timeout length may be inferred by the server, in order to resolve only after your inferred timeout. (this discourages timeouts. why?)
the "valid" reason to discourage client-enforced timeouts:
- ok i can't think of any
(a minimum wait time is very reasonable though. if you are actually just a queueing system like customsflare, this is a tool to modulate flow rate across multiple stochastic processes.)
the evil reasons to discourage client-enforced timeouts:
- you can do extra evil tracking stuff
- you can mine crypto
- you can contribute to a botnet ddos
- you can escape the browser sandbox via generic side-channel attacks like rowhammer along with cpu speculation like meltdown/spectre
- you can use browser-specific side-channel attacks to extract user credentials
- you may be able to trigger a separate RCE after port scanning the requesting client
those are all i can think of right now. please suggest anything i've missed!
as a purely practical matter, since i have observed that clownflare may require a hardware shutdown, i never switch tabs until the foreground tab is past the spinner.
this may sound boring—if so, please consider:
- either it successfully completes within expected time (no waiting, no boring),
- or, as every further second ticks past, the hype continues to rise, and the odds you're about to Observe an Event asymptotically hew to a rough sigmoid
it's worth noting that explicit censorship is extremely difficult to hide—instead of failing, clownflare waited several minutes before DoSing me. even if it wasn't actually rowhammer, it successfully censored the content by scaring the shit out of me.
[literally just a louis pouzin paper. they fear him so much.]
ACM flavored clownflare has one last trick up its sleeve: calling you a bot! this is clearly still censorship by our definition (and is frequently employed by github).
the much worse alternative: demanding a photo id or other form of identity to prove your identity! (bluesky continues to pop this up at random like that's not actual IBM and the Holocaust coded)
if you provide this, you are now at risk of identity theft and it's still censored. don't do it!!! it's a trap!!!
