Huh, what a blast from the past. About 30 years ago, in Russia, I hacked up cyrillics keyboard support for Coherent by extending the line discipline layer in its kernel. It was probably still Coherent 3.0 though (which IIRC was based on Unix V6?), and the one on github seems to be 4.2.x.
It's not based on V6, although it was basically created as a clone of it (and on the PDP-11, no less - the x86 versions of Coherent until 4.x were basically just minimal ports that kept the PDP-11's classic 16-bit flavour). It was a very very good clone, enough that a lawsuit was threatened and Dennis Ritchie himself got pulled into checking that it wasn't derived from any UNIX source - see dmr's comment at https://groups.google.com/g/alt.folklore.computers/c/_ZaYeY4...
Apparently there's no support for smarthost / relayhost (or I can't find any traces of it in the documentation). Running your own low traffic mail exchanger without it is often not a pleasant experience.
Hmm, interesting. Are you speaking from experience? Because I definitely am. I watched my mother die a very slow, very painful death from cancer several years ago. I can assure you she would be absolutely genuinely happy to get that cellophane hood and that nitrogen cannula. And, having seen what I've seen, I will also take the hood over some very real alternatives in a heartbeat. Playing dress up with this ridiculously futuristic glass coffin toy instead seems somewhat preposterous when you are facing death.
> In this case there's not many reasons for it to be a native app instead of a Progressive Web App. This would simplify distribution.
The opposite of this is true. Blocking a web application is very easy for Russian authorities, there are well-established legal and technical protocols for that, it's a routine, it happens every day. The opposition uses apps precisely because they are more difficult to censor.
So is this app using some other protocols that aren't DNS/http(s) that would make it immune to a dns level block? Because a native app that makes http calls is just as easy to block as a pwa
The app uses the same technology as some trojans: it connects to different pseudorandomly-generated domain names under Cloudflare protection, changing at least several times per day.
The client still needs to receive those domains somehow though, and that's the tricky bit. Unless the domains are unique per user, the blocker can just install the app and block the domains as they change.
You can embed the domains in the app, obfuscated. It's not foolproof but as long as they can't crack it in the few days that are left until the election...
Not really. You can use whatever you like, the possibilities are endless. AFAIU, the most straightforward approach would be to use Android / IOS push notifications (which can't be easily blocked) to regularly push a constantly changing (to avoid censorship) URL of your backend API servers to the mobile apps.
Unless those urls are unique per user, then the response to that is for the blocker (Russia in this case) to install the app and block the URLs as they change
They don't have to be strictly unique per user. You can send out different sets of URLs to different cohorts of users, then correlate new URL blockings with client IDs to detect rogue app installations and excommunicate them. Telegram did that when Russia tried (unsuccessfully) block it.
Given this is an app for tacical voting over a 2 day period (which has now passed) all the adversary needs to do is block it for a couple of days. Dns blocking cloudflare for 2 days would pretty much stop this in it's tracks.
(You are right about not requiring completely unique urls per user by the way).
No, it (again) doesn't work like this at all. 1) DNS blocking of cloudflare is useless, you can receive IPs, or names in non-cloudflare zones, 2) IP blocking of the whole cloudflare will bring so much collateral damage (unrelated services going down) that it's a non-starter, politically speaking, 3) cloudflare is far from the only mass frontend / cdn available, there are hundreds high-collateral services out there.
Sorry I misunderstood the fact that you were talking about sending IPs and not randomly generated dns name from cloudflare. My question was does this app use use a custom protocal, and I'd define a pseudo random IP provider over push notifications to be a cudtom prptovol.
This is a nation state suppressing information, I don't see why wholesale blocking services like cloudflare or any of the other possible options would be a non-starter, given it only needs to last for a weekend. There also doesn't appear to be any evidence that this app uses any of these techniques either as far as ive sedn.
The advantage of a web app is that it can be distributed in any number of ways though. It's trivial to take it and re-host it on different servers, as an onion service, or go the full decentralized route with IPFS or similar.
Yes, you can re-host, but propagating the new URL to your users will take days, and the authorities reaction time is, for high profile cases, measured in hours. Another interesting question is how will you propagate the new URL? To do that, you need some way to reach your users when your website is down. And if you have such a way, do you really need a website?
Just e-mail people an update from random address with GPG signature. That should be the more resilient and hard to block way to communicate information. It's fun when the old proven tech proves superior to new shiny tech.
Just as the gov required google to remove the app they can also require the big email providers to block all emails with links to it.
99% of the people are on the big email providers.
Also, you will quickly find out that sending many emails from random addresses (ie: spamming) doesn't work these days, they will be blocked by existing anti-spamming techniques, as evidenced by multiple posts on HN of people trying to do that from their own mail server.
You need to go through a whitelisted mail service (MailChimp, ...) which is another block point.
> Just as the gov required google to remove the app they can also require the big email providers to block all emails with links to it.
You don't need to mail links, you just need to mail required information. Asking Google to filter out some specific e-mail (which could be somewhat randomized for every recipient) probably will not work.
> You need to go through a whitelisted mail service (MailChimp, ...) which is another block point.
Russia can't ask US service to deny making business with US citizen (for example). It's completely outside of their territory.
> Russia can't ask US service to deny making business with US citizen (for example). It's completely outside of their territory.
Not sure what US citizens have got to do with this. Russia obviously was able to order Google to block relevant apps and documents for Russian people. Why would they care that US citizens can still access them?
Not now, but people adapt when there's an incentive.
Already if you go in a country with restrictive internet, you'll find the average working-age person knows how to use a VPN. Regular drug users in western countries know how to use Tor. Hong-Kong protestors were using a bluetooth mesh network app.
I'm not sure about Tor, but I know from my friends in Russian, who have direct access to this information, that the Russian government inherits all the practices and technologies from China, with DPI and all the things.
Now even VPN + shadowsocks won't be a permanent solution.
It's obvious cooperation of governments that can help each other, one with tech to control, and the other with cheap resources for manufacturing. (you can google how Russian almost sold part of territories to China, there are even cities where all the administration are Chinese).
Not as of yet. Actually, if you use tor (with out-of-Russia exit nodes, which I think is the default when using it from Russia?), you can already freely access all the sites blocked in Russia, non-onion ones. But, obviously, tor and VPNs are good solutions only for people willing to go an extra mile to get to the prohibited content.
It now has the option to avoid (laggy) Android media service framework, and to use its own scanner to detect media changes instead. That should be immediate.
You are mistaken. PRISM is specifically a program that "collects stored internet communications based on demands made to internet companies" [em. mine]. NSA wiretapping the non-public links of Google et ol was not PRISM (I'm not even sure that the name of that program was ever disclosed).
The NSA placed key people into companies like Google who had security clearances that specifically forbade them from saying exactly what they were doing to higher ups. They then created systems for extracting data in an automated way based on requests from the NSA. All that executives knew was that they were doing something important for complying with law enforcement requests.
The CEOs of these companies learned about the existence of the back doors from public reporting based on Snowden's revelations. When they first heard, they issued public denials that were, as far as they knew, truthful. Their subsequent actions upon finding out that they were wrong strongly suggest that they wouldn't have approved the programs had they known what was happening.
I see this claim is made in the Wikipedia article [https://en.wikipedia.org/wiki/PRISM_(surveillance_program)]: "PRISM collects stored internet communications based on demands made to internet companies such as Google LLC under Section 702 of the FISA Amendments Act of 2008 to turn over any data that match court-approved search terms.[6]" but the cited source [https://www.washingtonpost.com/world/national-security/nsa-i...] does not support this assertion; on the contrary it explains "[NSA] has secretly broken into [...] Yahoo and Google". It certainly doesn't make the stronger claim you seem to suggest here that PRISM is limited to FISA requests.
You probably meant to say "shikantaza", I don't think "shinkanzen" is a word.