Issues that apply to multiple Awala-related projects from Relaycorp
Home Page: https://github.com/relaycorp/relayverse/issues
Yes. Many potential couriers may not have heard about it until they found themselves in an Internet blackout, but they should still be able to start relaying data without the Internet.
A "Courier's Pack": A collection of some/all of the following files:
The files above could also be distributed over BitTorrent/IPFS and sneakernets like El Paquete Semanal.
Internet blackouts are generally part of a broader telecommunications blackout (e.g., Kashmir in 2019-2020), but it's not uncommon for the telephone service to remain operational (e.g., Belarus in August 2020). In such cases, we could leverage the telephone service to connect: private gateways to public gateways, private gateways to couriers, private gateways to private gateways, and couriers to public gateways. This is an issue to explore the option to do this without a physical modem.
In principle, I think it'd be good to use a pre-existing/well-known technology to convert an analogue signal to a digital one, like a soft dial-up modem (e.g., android-fskmodem).
This soft modem would be integrated in the mobile implementations of the private gateway and courier apps, so that both end users and couriers can use it.
We could do one/all of the things below sorted by preference:
Most of these changes shouldn't require changes to the protocol suite.
Given the low throughput of this method, it'd be good to support the Quality of Service extension by then: AwalaNetwork/specs#59
This idea is just a hypothesis at this point so we need to validate it first. Some of the questions we'll have to answer include:
Instead of using dial-up soft modems, use another method to convert between analogue (voice) and digital signals. This would allow us to use steganography, which could be useful if the phone is likely to be tapped. However, a big disadvantage of this method is that -- even without the steganography -- the throughput would be very low, so adding steganography would make it significantly worse.
An attacker may set up public gateways on domains that look like one from Relaycorp (e.g., frankfurt-relaycorp.cloud) and then convince their victims to migrate to that gateway. Or they may use domain names containing the word "Relaynet" (e.g., relaynet-gateway.com) to pass off as an "official" gateway.
Block domain names containing the words "Relaycorp" and "Relaynet", but allow subdomains of .relaycorp.cloud. Also block misspellings of the two words (e.g., "Relaycopr", "Relyanet", "relay-net"). Punctuation should also be ignored, meaning that a domain like relay.net or relay.corp.cloud should still be blocked.
We should go through all the Android Apps and update the compile and target SDK to api 33.
As we already saw with Courier #596 this change might require a few changes in the code base to support the newest version of Android.
It'd be nice to give this option to people who:
The PKI spec defines an optional extension to rate limit incoming messages from authorised endpoints, but this extension isn't currently implemented.
By implementing it, we'd be protecting private endpoints from DDoS attacks (as long as service providers configure the rate limiting properly).
The Android Keystore doesn't actually encrypt anything on Android 5 and 5.1.
We should warn users about this, and encourage them to enable full-disk encryption to mitigate the risks (although, unfortunately, not all Android 5 devices have this capability). Or, if possible, upgrade to an Android 6+ device.
Alternatively, we could prompt Android 5 users for a password and handle the encryption at rest ourselves, but this option has two major drawbacks:
For context, as of January 2021, Android versions 5.0 and 5.1 combined represent roughly 10% of Android devices according to Android Studio.
Yes. Many potential users of Awala may not have heard about it until they find themselves in an Internet blackout, but they should still be able to start using it without the Internet.
A Awala User's Pack: A collection of some/all of the following files, which will be distributed by couriers and other users:
The courier apps could run an HTTP server to share those files when users are disconnected from the Internet, similar to how the Knapsack desktop app does it -- In fact, the files above could be great candidates to broadcast over Knapsack. To keep things simple, at least initially, couriers should be able to disable this functionality to save disk space, but they shouldn't be able to customise the files.
The files above could also be distributed over BitTorrent/IPFS and sneakernets like El Paquete Semanal.
See also #2
There's a very serious lack of literature on how to approach UX in DTN.
The Offline First movement was a step in the right direction, but it's not active these dasy and its primary focus was Progressive Web Apps (PWAs). However, the scenarios we're dealing with are more extreme than the ones PWAs were designed to support (e.g., the user may never connect to the Internet, the user may be under a lot of stress due to civil unrest).
I think we should try reaching out to the following communities and see if there's any opportunity to collaborate:
I've registered dtn.design in case we want to use it.
As of late 2023, we're requesting funding from the Open Technology Fund to do this in partnership with Neighbourhood.ie.
This library would be used to share any code that needn't/shouldn't be in the core JVM library. Basically, anything that's just an implementation detail -- as opposed to a protocol requirement/recommendation -- should be here. Examples:
https://awala.network/archives/ux-assessment-2021.pdf
To properly fix issues such as relaycorp/relaynet-core-js#52 and more.
Users currently need to install a separate app (the private gateway) in order to get their Awala-compatible apps to use Awala, which poses a barrier for new users. I think we can reach a compromise by making the gateway optional but only support a subset of the functionality when it isn't installed.
Ironically, we mainly need it for UX reasons when the Internet is unavailable: We need a single app to synchronise data with couriers. If we didn't have a single app, each Awala-compatible app will have to be responsible for synchronising data with a courier, which would be terrible from a UX perspective, as well as a big burden on the service providers.
The second reason is to ensure fair use when the Internet is available: Relaycorp-run public gateways will be open to any anonymous user (no registration required), so having a single client per device will at least make it possible/easier to ensure fair use.
The third reason is efficiency and performance. If a user has multiple Awala-compatible apps on the same device but the private gateway isn't installed, those apps will be doing a lot of work that could just be delegated to a separate app (i.e., the private gateway). Not to mention that this would also make those apps bigger.
I think we can make the private gateway optional whilst addressing the points above by implementing a separate flavour of the endpoint libraries that will connect to public gateways/endpoints directly when there's no private gateway locally.
However:
On the plus side:
Time to upgrade from Kotlin 1.6 to 1.8 across all libraries and apps. Here's the plan:
This is what users see today on Android and desktop when they're not connected to the Internet or a courier:
It'd be good to offer some help in case they're trying to connect to a courier, but aren't managing to do so. For example, we could display a button that says something like "I can't connect to a courier", which opens a screen that shows information like:
Internet apps are responsible for the transport of the data they produce and consume, so circumventing Internet censorship requires a system-wide tool on the user's device (e.g., Tor, VPNs) or a custom technology built into an app (and/or the servers it talks to).
By contrast, Awala apps delegate the transport of their data to the local Android/desktop gateway, whose sole job is to connect the local apps to the outside world using the best network available. So it makes sense for it to also be responsible for circumventing censorship when using the Internet, so that Awala users, couriers and service providers will never have to worry about Internet censorship.
Tackling this issue soon is very important for three reasons:
This is a meta issue for all the changes we'd have to make to the Awala protocol suite and/or Relaycorp's implementations.
Internet censorship is implemented differently by country, and even by ISPs within the same country. This requires us to employ a variety of technologies and techniques -- some of which may have to be limited to certain countries/regions if they incur a performance penalty, for example.
Fortunately, today we can leverage the amazing work by the Internet Freedom community, who's been documenting censorship techniques and designing/developing circumvention tools. We'll achieve the goal of this issue by building on the their work and contributing back when possible.
We already have plans to support the following technologies, not just to circumvent censorship, but also to improve privacy and scalability:
cloudflare-dns.com) can't be resolved.To circumvent censorship when necessary, we may use the following technologies/techniques in certain cases -- starting with the ones that seem more robust, easier to implement and less likely to cause performance/UX issues:
It might be good to consider Pluggable Transports as a stopgap solution, but whilst think they're great for regular Internet traffic (i.e, RPCs), I think integrating them in a Delay-Tolerant Network like Awala will involve some pretty serious shoehorning -- and I believe the techniques above offer equal or better UX/performance anyway.
We should also consider how to onboard users when they can't download the desktop/Android gateways (see also #1). For example: People who haven't yet installed the desktop/Android gateway should be able to send an email to something like [email protected] to get an automatic reply with an installer (instead of the full app, as that'd take up more than 10 MiB). The installer itself should be able to bypass Internet censorship too.
I've identified the following (surmountable) challenges:
I can't think of any disadvantage to circumventing Internet censorship via Awala compared to using VPNs, nor can I think of a single reason why placing a VPN in front of a gateway or courier app would be useful.
Putting censorship circumvention aside:
I believe Awala would be at least as effective as Tor at circumventing censorship and it'd be more performant, but Tor would still provide better privacy because the user's IP address is never revealed to the target server. Consequently, many whistleblowers, activists and journalists may still prefer Tor -- Until a reputable third party agrees to operate an Awala-Internet Gateway with a strict no-logs policy (which Relaycorp is extremely unlikely to do).
The above can only work if the global Internet is at least partially reachable to end users or intermediaries. It's also less likely to work if the censor employs an allowlist approach where only selected IP addresses can be reached, unless the allowed services can be exploited (e.g., email).
fix prefix for production dependecies. Example: relaycorp/awala-gateway-internet@27ec7c1git diff | egrep --quiet " (api|implementation) " should do the trick.package.json, build.gradle) should be modified. File additions or removals should be refused.This is a protocol-level issue (AwalaNetwork/specs#74) which will require changing the gateways.
https:// prefix from public addresses.Relaynet with Awala in RAMF signatureshttps:// prefix from public addresses.Relaynet with Awala in RAMF signaturesVirtually all TLDs support DNSSEC these days, but the degree of security varies wildly by TLD; for example, some still use insecure algorithms (e.g., .apple uses SHA-1), and some are operated from jurisdictions under repressive regimes (e.g., most Chinese-language gTLDs are operated from China). Additionally, DNSSEC currently lacks key transparency measures.
Domain operators should be aware of these issues when they rely on DNSSEC, but it's really hard to do so today.
A website where each TLD gets a page with the following:
We should also publish a page for each operator/backend and document the following:
.fans is operated by CentralNIC in London but its sponsor and administrative contacts are in Beijing -- could China theoretically compromise the .fans zone via those Beijing-based companies under exceptional circumstances (e.g., a war)? I'd say 'no' based my conversation with IANA (see below).Adding this information to existing websites, like ICANNWiki or nTLDStats, but it feels completely outside of their current remit.
I got in contact with IANA regarding the procedures that IANA and TLD sponsors/administrators/backends must adhere to, and got the following reply from Amy Creamer on 12th August 2022:
- Does IANA regulate in any way the role of the Sponsoring Organisation, Administrative Contact or Technical Contact for each TLD delegation? RFC 1591 simply mentions these roles.
These roles are defined for country code Top Level Domains (ccTLDs) in the Framework of Interpretation of RFC 1591 at https://ccnso.icann.org/sites/default/files/filefield_46435/foi-final-07oct14-en.pdf, and IANA requires that all applicable ccTLD policies and procedures be met by the ccTLD. For generic top level domains (gTLDs), these roles are contained in contracts the gTLD Registry holds with the Internet Corporation for Assigned Names and Numbers (ICANN). All gTLD contracts are made public and can be found here: https://www.icann.org/en/registry-agreements?first-letter=a&sort-column=top-level-domain&sort-direction=asc&page=1.
- Does IANA have any mechanism to monitor and/or penalise TLD managers that sign fraudulent DNSSEC records? For example, DS/DNSKEY (for phishing purposes) or NSEC/NSEC3 (for denial of service purposes).
This is not within IANA’s remit.
I will answer #3 and #4 together, below:
3. Does IANA require any specific procedures on the generation, use and eventual destruction of cryptographic key material used by TLD managers for DNSSEC purposes?
4. Are TLD managers required to share their DNSSEC key management procedures with IANA, and if so, can third parties have access to them on demand? These are certainly not made available to the public generally, but I wonder if at least IANA has access to such documents.There are provisions for DNSSEC in the gTLD Registry contracts with ICANN. The most recent contract can be found at: https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html
In the contract I suggest you review:
“SPECIFICATION 6: REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS
DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of and zone files used for in-bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Registry Ope
rator shall publish its DPS following the format described in RFC 6841. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at https://www.iana.org/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.”One example of a Registry publishing on its website the DNSSEC Practice Statements (DPS) can be found for .apple here: https://www.apple.com/legal/intellectual-property/tld/dps/
For the case of ccTLDs, they are governed locally within their country for anything that goes beyond the scope of ccTLD policies and procedures.
Having the creation date is causing more trouble than it solves (e.g., relaycorp/relaynet-gateway-android#251, relaycorp/awala-endpoint-android#34).
So we should just have the expiry date (replacing the TTL since there wouldn't be any time reference any more).
Couriers currently have to stop at a location with access to the Internet so that they can relay their data. However, there's no reason why they couldn't just hand it over to another courier if the initial courier won't be able to stop by a location with access to the Internet.
Like real-world couriers, this could be solved with a "transport hub":
Additionally, either type of courier may have a location with access to the Internet as one of its stops -- in fact, at least one courier route in any region must have one.
This transport hub app would have to keep track of the route for each courier that connects to it and the private gateways whose cargoes have gone through it recently (along with their corresponding routes), so that it route cargo to the appropriate routes.
Note that the app wouldn't need to know the actual stops in the routes. It just needs the id of the route, whether one of the stops provides access to the Internet and the id of any other transport hubs found in the route.
See also:
Using something like https://www.katacoda.com/, for example.
So that we won't have to use HashiCorp Vault in production.
I would've liked to use KMS instead of Secret Manager, but PKI.js currently needs direct access to the private keys.
Use Mozilla's as inspiration: https://www.mozilla.org/en-US/foundation/trademarks/policy/
We'd need to build three things to achieve that:
Implementing a courier app is outside the scope of this issue. See #5.
We have to port some backwardly-incompatible changes from the JVM lib in order to fix a wider issue in the protocol. I already ported them to the Courier app but we still have to port them to the Ping and Gateway apps.
The high-level changes are:
Parcel.validate()/Cargo.validate() used to take two parameters (recipientType: RecipientType, trustedCertificates?: List<Certificate> = null), but now it only takes the optional parameter trustedCertificates. This means that we might have one redundant test after this change, which should be removed.So this is basically what we have to do:
awala and awala-testing to the latest versions in the endpoint lib. Whilst we're there, we should also rename all variations of the terms "public address", "public gateway" and "private address".awala and awala-testing to the latest versions in the Awala Gateway. Whilst we're there, we should also rename all variations of the terms "public address", "public gateway" and "private address".Essentially port the Android app to iOS.
See also #6
As a workaround for PeculiarVentures/PKI.js#287, I had to downgrade the cipher mode from GCM to CBC across the board. This is OK for the current phase of Relaynet, but the lack of authenticated encryption is going to block the eventual General Availability of Relaynet.
Note that the lack of support for AES-GCM is a violation of RS-018: https://specs.relaynet.network/RS-018#symmetric-ciphers
The eventual fix should reinstate support for AES-GCM and make it the default, whilst still supporting AES-CBC for backwards compatibility.
See also:
Work with partners to produce such tailored recommendations in the respective local language(s). I believe most -- if not all -- of the documentation will be to guide couriers on how to relay data safely and efficiently.
This documentation is to be published on the appropriate website (e.g., relaynet.network, relaynet.red), as well as the respective apps (i.e., the courier and Relaynet apps).
Apart from our own libraries, apps and cloud infrastructure, we should try to get the following third-party dependencies audited too:
PKI.js (at least Certificate, EnvelopedData, SignedData and their internal dependencies).@peculiar/webcrypto and webcrypto-core (at least the algorithms we use).asn1js.@stablelib/aes-kw (used in Electron apps only)I've been putting this off due to the nightmares caused by the Kotlin 1.5 upgrade, but I'd like to think it'd be different this time.
The most important lesson I learnt last time is to do the upgrade in the following phases, to make debugging manageable:
* I'd rather defer the upgrade to ktor v2 if we can, because that's a mini project in its own right.
Thoughts, @sdsantos?
Here's how it can be integrated with Axios: https://github.com/ptariche/fdoh/blob/HEAD/examples/axios.js
Use a resolver approved by Mozilla: https://wiki.mozilla.org/Security/DOH-resolver-policy.
Consider requiring/recommending this at the protocol level. I was torn about it.
We'll eventually need a system to track potential Internet blackouts in the future so that we can prepare for them properly for three reasons:
The plan is basically to rate the likelihood of an Internet/telecommunications blackout due to a future event, such as controversial elections in a country where the Internet has been cut off in the past, for example.
The input data should ideally be crowdsourced. For example, people could be editing YAML files in a GitHub repo.
This data should be exposed in a number of ways:
.ical files that people like me could add to their calendars. There could be country-specific calendars.This would be open source (obviously), and it'd be great to partner with others in the censorship measurement space. This could be hosted on blackout.observer.
Note that we're only interested in Internet blackouts, not shutdowns (which can be circumvented with Tor/VPNs). However, if anyone wants to build and maintain the functionality to report on future shutdowns, they'd be welcome to do so. I've also registered shutdown.observer in case the project evolves into that.
We could keep the monitoring informal and manual, with no automation whatsoever. That's what we have to do for now anyway, and it's also a great way to learn what we actually need. But I don't think a manual/informal process will be sustainable for too long.
I also did some research but could not find anything that would satisfy the requirements above. All the initiatives I've found measure/analyse past and/or ongoing Internet blackouts, but no-one seems to be systematically documenting Internet/telecommunications blackouts that could happen in the future -- the closest thing to this is the Access Now blog which occasionally highlights potential blackouts (but most posts are unrelated).
I haven't been able to get BouncyCastle and PKI.js to exchange mutually-compatible KeyAgreeRecipientInfo values. See:
Note that both the JVM and JS libraries of Relaynet support the Channel Session Protocol. The problem is that their implementations are incompatible, which is why gateways and endpoints are not using this protocol yet.
See also: AwalaNetwork/specs#84
Any user that installs an Awala Gateway is told that they also need an Awala-compatible app, yet we don't offer any pointers on how to get one, so we're basically relying on users finding out through other means.
We should offer the option to install Letro and maybe one or two additional apps. If the Internet is available, the apps would be installed via the Google Play Store; otherwise, they'd be scheduled to be downloaded from the courier (at the next sync).
Recommending a Relaycorp app like Letro is inconsistent with the spirit of net neutrality, although technically not a violation IMO, so we'd have to amend our T&Cs to explicitly allow this just to be safe.
We could require users to install F-Droid or Butter, but that'd be yet another app that they'd need to install. Plus, how do they get F-Droid/Butter if they don't have access to the Internet?
We should avoid encouraging users to sideload apps as it's too dangerous and Google refuse to make it safe.
The algorithm should only be used to compute the first character (aka version) of the address (e.g., 0 for RSA-PSS with SHA-256), but it shouldn't be part of the input to the hash of the public key.
The problem with algorithm params is that, unless they're normalised, subtle discrepancies will result in different private addresses. Also, most implementations (e.g., GCP KMS, PeculiarVentures/webcrypto) will output RSA algorithm params as NULL when exporting public keys, but another implementation could/should specify the parameters.
I think that the worst thing that could happen is that things will occasionally break for mysterious reasons if an Awala node exports a public key with RSA algo params other than NULL, but this is very unlikely to lead to security vulnerabilities because we're still using a X.509-based PKI.
See also:
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.