chaospatterns

If the app is just a WebView wrapper around the application, then the challenge page would load and try to be evaluated.

If it's a native Android/iOS app, then it probably wouldn't work because the app would try to make HTTP API calls and get back something unexpected.

On Tor dark web domains, you use the .onion domain. Tor is configured as a SOCKS proxy, so it doesn't perform a DNS query. Instead, Tor itself sees you're trying to connect to an onion domain name. Then it takes the URL and translates that into a public key that it knows how to find in its own hidden service directory.

Only the actual hidden service has a valid private key corresponding to that public key in the URL so cryptography (and the assumption that quantum computers don't exist) ensures you're talking to the right server.

Tl;dr effectively no DNS for onion hidden services

https://community.torproject.org/onion-services/overview/

Putting the charger circuit inside the battery takes away battery capacity, so I still buy the external chargers

Unless you're running VLANs, in which case the inter VLAN is normally handled by the router. I also expose my home lab services over BGP so all my traffic hits the router then comes back to my lab services.

Every WiFi router and network has something called an SSID and a BSSID. The SSID is the friendly name that you use to show off your puns to your neighbors. The BSSID is a 6 byte MAC address. All devices use the BSSID when connecting and communicating.

With a non hidden SSID, your router broadcasts the SSID and BSSID.

The BSSID doesn't change even if you change your SSID (Though APs with support for multiple SSID create a different BSSID per network) and it's what is actually used for geo location.

When it's hidden, it doesn't send the SSID out, but sends out packets with the BSSID. Clients then scream out to the void "anybody know the SSID 'My Secret SSID??'" Then it'll respond.

So basically hidden networks still send out the unique identifying address and then when you take your phone with you, you're just telling everybody what your home WiFi is called.

Hidden SSIDs are not that useful.

https://forum.syncthing.net/t/discontinuing-syncthing-android/23002

According to this post, it was partly that and lack of maintainers. Given there's maintainers for a fork, I'm curious why they didn't bring them into the main project.

Reason is a combination of Google making Play publishing something between hard and impossible and no active maintenance. The app saw no significant development for a long time and without Play releases I do no longer see enough benefit and/or have enough motivation to keep up the ongoing maintenance an app requires even without doing much, if any, changes.

We're sort of in this situation because the official project decided not to continue providing an official Android app, yet people want to use it on Android forcing unofficial versions to be created and maintained.

I get that they don't want to deal with Google Play anymore, but somebody has to deal with it and them not owning the app is putting users at risk.

I tried that with my KeePass database and then I ended up with different conflict versions if a device didn't sync to my server before I updated on another device. Then I ended up with the conflict versions and old versions I had manually resolve. The Android Syncthing app could get auto killed by the Android OS for memory/battery saving, so I had to go back to OneDrive style syncing where the KeePass Android app would internally merge and resolve conflicts. It couldn't do that using the Syncthing style syncing.

How would that work? The use case is for previews for pull requests. Somebody submits a change to the website. This creates a preview domain that reviewers and authors can see their proposed changes in a clean environment.

CloudFlare pages gives this behavior out of the box.

It is for pull requests. A user makes a change to the documentation, they want to be able to see the changes on a web page.

If you don't have them on the open web, developers and pull request authors can't see the previews.

The issue they had was being marked as phishing, not the SSL certificate warning page.

Some people are asking why other regions seem to be affected when us-east-1 goes down. Why aren't they separated out? I used to work in AWS, but will speak generally.

First, it's important to understand the concept of a control plane vs a data plane. Amazon and other big scale companies often talk in terms of control plane/data plane separation because those two concepts have wildly different scale and requirements.

A control plane is the side of your service that handles the administrative functions of a service. For example, AWS S3 service would separate out bucket creation and deletion work from the file create/edit. In Route 53, this would be creating and editing zones. In IAM, it's the creation of AWS access keys for IAM users. IAM Roles, IIRC, work differently and can function more in the data plane.

A data plane is the side of the service that handles the main meat and potatoes of a service. For example, AWS S3 any object key creates, edits, deletes would all be part of the data plane. In Route 53, these would be any DNS record query. I don't know if updating a record was considered a data plane call or not.

These are separated out because data plane generally massively dwarf the number of calls for administrative APIs. It's also done because control plane calls often times have some extra complexities. Like in Route 53, to create a zone means you need to go find n different name servers that can handle a given domain name without overlapping with another customer, you need to tell them that they should now handle calls, you need to get the records to those servers running all over the world.

The fact is Route 53 is globally replicated and they need to have a source of truth and engineering culture pushes Amazon towards a pull based approach. If a user creates a zone in eu-west-1, they still expect it to be on servers all over the world, so how do you get it there? Well, AWS takes the approach that certain services can have a single region dependency for their control plane in the case that it's infeasible technically or to the business to avoid one, however the data plane of the service can't have that dependency.

N. California as a region can't grow and it's priced accordingly. Instead, compare US East (Ohio) or US West (Oregon) for a region that's price competitive. A lot of Amazon internal stuff was starting to move to US East (Ohio) because it was geographically close, but a lot less problematic.