HN user
Cloudflare uses JA3 and now JA4 TLS fingerprints, which are hashes of various TLS handshake parameters. https://github.com/FoxIO-LLC/ja4/blob/main/technical_details... has more details on how that works, and they do offer an Nginx module: https://github.com/FoxIO-LLC/ja4-nginx-module
Will Prowse's favorite large panels are cheaper than that, including a 370w bifacial for $111 each in small quantities: https://signaturesolar.com/all-products/solar-panels/
Related video: https://www.youtube.com/watch?v=v33nbi7gKcY
By default, many compilers include things like local filesystem paths, build server hostnames, or build timestamps into their binary artifacts. These will obviously differ build-to-build.
Even without that, it's possible to accidentally leak entropy into the build output. For example, readdir() doesn't guarantee any kind of ordering, so without sorting the list of files it is possible for a binary artifact (or even tar) to produce different output from the same input.
Over the years, I've had direct knowledge of or involvement with maybe a dozen or so events that have ended up in the mainstream news. And in almost every case it has been inaccurate in some way, sometimes getting basic facts wrong and others having significant bias or spin that was misleading.
This hasn't given me great confidence in the accuracy of the reporting for things that I don't have direct knowledge of.
On cell networks, video content is by far the largest consumer of bandwidth. And the default for video generally is to auto-adjust the resolution to the highest quality that the network supports. This kind of sucks, since bandwidth is a shared resource for all users of a given antenna on a cell tower.
Though Speedtest on your cell might show your connection speed as 100 megabits/sec down, cell networks special-case video by identifying it as video and rate-limiting it to something like 1 megabit/sec. This is considered "efficient network management". For T-Mobile, this based on the plan (https://www.t-mobile.com/cell-phone-plans), they sell either "SD streaming" or "4k UHD streaming". "SD streaming" is a fancy way to express that they rate-limit identified video streams to 1 megabit/sec.
They identify video streams by watching the IP your phone is connecting to and/or the hostname mentioned in the TLS SNI header and checking if it is Youtube, Netflix, etc. Sending video content over a VPN removes their ability to understand what the content is.
The default region for global services including https://console.aws.amazon.com is us-east-1, but there are usual regional alternatives. For example: https://us-west-2.console.aws.amazon.com
It would probably be clearer that they exist if the console redirected to the regional URL when you switched regions.
STS, S3, etc have regional endpoints too that have continued to work when us-east-1 has been broken in the past and the various AWS clients can be configured to use them, which they also sadly don't tend to do by default.
Enabling Warp via the "1.1.1.1" Android app gets me an 8.x.x.x VPN address, at least. This /24 appears to be routed to my city's Cloudflare node, so presumably there's a /24 per city they run this service in.
Running a quick port scan from my phone against one of my machines works, so it doesn't look like they are restricting this too heavily.
And I'm not logged into this app and haven't granted it additional permissions, so I'm not sure they have any idea who I am here.
It's not edge location count that matters, but Cloudfront doesn't use BGP Anycast but rather does a more traditional DNS-based routing and tries to spread the requests across multiple edge locations (even those farther away) for redundancy, intentionally.
When I asked for detail about why they don't use Anycast, the Cloudfront engineering team basically said their customers care more about uptime than latency and that full Anycast was too sketchy. Apparently amazon.com disagrees, at least. I'm also happy getting much lower first page view latency out of Cloudflare.
We weren't having issues solved by basic documentation.
In the most recent example, we were occasionally hitting Java heap OutOfMemory under our workloads and wanted tuning or even architectural advice. It turns out that ElasticSearch didn't limit ingestion rate to control memory pressure and was happy to accept writes under load until it exploded. Heavy users of ElasticSearch commonly have to watch ES memory pressure and throttle their own writes client-side.
I would've loved to hear these limitations from elastic.co, be offered some tips on appropriate techniques for throttling, or have them accept a feature request to better handle this server side. We never got anywhere near that level of depth of understanding our problem, after months of trying. It felt like we were talking to first-level support who didn't understand the product much better than we did.
Not much value at all, from my experience.
Having given Elastic's support two tries at different companies, it doesn't surprise me that their business model is failing. Their support was _terrible_ both times; at no point were we ever in touch with anyone who seemed like they understood the product, cared about our issues, or were in any hurry to fix them. We were locked in year long, 6-figure support contracts in both cases, and issues dragged on for months until we basically gave up. We got better answers out of random Google searches and a 20 minute conversation with a friend of a friend.
AWS's hosted ElasticSearch only recently is able to handle the data set sizes we were dealing with, and their enterprise support on this (and other products) is vastly better than anything we ever got out of Elastic.
Based on reading the LinkedIn of the Parler execs, their code is node.js and some Go with Cassandra and Postgres for storage and RabbitMQ for queuing. That sounds like it will run anywhere they can rent a pile of Linux boxes.
They've tried to avoid lock-in, specifically mentioning avoiding any Google technologies in their mobile apps. However, they are using Route53 for DNS, Cloudfront as a CDN, and ALB for load balancing, so there are a few commodity services they'll need to swap out.
Where did you see the "per month" for Travis? The 10,000 free credits are a one-time trial from what I can see.
Wasn't it only has of version 3.4 that Jepsen stopped finding single-node data loss bugs in MongoDB? So it's been 3 years that MongoDB has been suitable for single-node data storage, and apparently 5 months that it's been reasonable to use in a sharded deployment.
Perhaps in another decade, MongoDB can shed its well-earned reputation for eating data.
Skimming the bucket code, it appears that the rate-limiting information is stored in a map. It doesn't appear to implement an LRU or attempt to clean up stale entries.
If I feed this user-supplied keys such as IP address or cookies, doesn't this mean it will grow without bound?
Previously when the Wired article was mentioned on HN (https://news.ycombinator.com/item?id=5089703), I did some digging and found that aaronsw.com and tor2web.org were hosted on the same Linode instance IP.
While the sniffing could've happened at any Tor exit node, Tor2web is an insecure public interface into the Tor network and is uniquely positioned to sniff any traffic passing through it. Aaron Swartz could've had tor2web.org record any requests made through it and supplied any interesting results to Wikileaks.
Recent Android on T-mobile US uses IPv6-only transport. T-mobile's DNS servers are only asked by these devices to translate hostnames to IPv6 addresses. If they can't find an IPv6 address, they will look up the IPv4 address for a hostname, and pack it into the bottom 32 bits of an IPv6 address that routes to a IPv6-to-IPv4 NAT device at T-Mobile.
This is called DNS64/NAT64 and has some small performance penalty. Making content directly accessible by IPv6 removes the penalty.
That was an explicit goal of OpenBTS when I was following it years ago. The GSM vendors want something like $250k per base station, which is unreasonable for third-world or very-rural applications. OpenBTS thinks they can get the radio hardware costs down to a tiny fraction of that to serve low volumes, backed by a Linux box running this software.
Interestingly, their first large-scale field tests were at Burning Man (http://openbts.sourceforge.net/FieldTest/), where there were thousands of active GSM handsets but no cell coverage. They were able to provide limited SMS support between local participants and in later tests allowed some outgoing VoIP calls.
There's a TPM-like mode with hardware isolation built into ARM for years, used for disk encryption keys, DRM, auth keys, fingerprints, etc on IOS and Android. See: https://en.wikipedia.org/wiki/Trusted_execution_environment
Do they just strip the color profiles? Or do they apply them and convert to sRGB?
That depends on how you define fair, I guess. If this isn't a hardcoded bonus for "google.com" and instead all established, high-PageRank sites receive the same benefit, is it still not fair?
There's a not well-known component of Google ranking that acts sort of like a slow-moving, domain-wide PageRank. And because they launched domains.google.com as a subdomain of google.com, which contains PageRank 10 pages and is therefore very trusted, the assumption is that domains.google.com is also very trusted, even though it currently seems to have no inbound links from other google.com pages.
This effect is usually hidden because it's rare to have a highly ranked page with no obvious inbound links competing on an established keyword.
The lack of provider competition isn't a natural monopoly. It's a government-created monopoly/duopoly in a given market. Instead of regulating the one or two providers in a market, we could try a different model that improves competition.
One way is to do city-owned and maintained layer 1, like Chattanooga (http://money.cnn.com/2014/05/20/technology/innovation/chatta...), and sell access to as many ISPs want it.
The other way is to break the city franchise model. Cities generally grant franchise rights to cable and phone companies, excluding other providers for a promise of universal coverage and a few percent of the revenue.
The latter is what Google Fiber is asking for from the cities it goes into:
- It wants blanket access to all of the telephone poles and other right-of-ways, without having to do per-pole applications, application fees, and approval process that can take weeks/months each.
- It wants to not have to do universal access, but rather only roll into neighborhoods with a high enough density to be profitable.
- It won't pay the city a percentage of revenue. Instead, it agrees to build out free internet access to schools, public spaces, etc.
Google Fiber's model has the advantage of not relying on a city to properly maintain a fiber network, but the disadvantage of leaving poor communities un-served.
That depends on how you define "wide scale infrastructure sabotage". I believe that this is resulting from: https://blog.torproject.org/blog/tor-security-advisory-relay...
January 30 to July 4, 2014 someone set up 115 tor nodes on fdcservers.net (total cost maybe ~$200k?), which was 6.4% of entry guard capacity. Clients talk to 3 guard nodes for an average of 45 days each, which means they probably picked a guard ~12 times during this period. Each guard-picking attempt had a ~6.4% chance of landing one of these bad guards, or a 55% chance across all attempts.
"We know the attack looked for users who fetched hidden service descriptors... The attack probably also tried to learn who published hidden service descriptors, which would allow the attackers to learn the location of that hidden service."
I grant the docker.io build and private repository service access to my github repo, drop a Dockerfile at the root of my git repo, and the build server does the checkout outside of the Dockerfile and then executes the Dockerfile. I then use a github webhook to trigger a build when there's a new checkin to the master or qa branches. If the dockerfile completes successfully (based on exit status codes), it then spits out new docker images tagged with either "master" or "qa".
My fleet unit does a docker pull before it starts the container. So I just stop and start an individual unit to get it to run a new version.
Though fleet has a concept of global units (that run on all available machines), there's no way to do a rolling restart with them yet. Instead, I use unit templates to launch multiple instances of the same unit, and then stop and start each instance individually, and wait for it to respond before continuing to the next one. I intend to catch a webhook from the build server and do this automatically, but haven't written this yet.
We're moving all of production in EC2 from an old CentOS 5 image managed by capistrano to CoreOS, with fleet deploying images built by the docker.io build service and private repo. I love it.
Every week, we rebuild our base image starting with the latest debian:stable image, apply updates, and then our apps are built off of the latest base image. So distro security updates are automatically included with our next deploy.
We had been deploying multiple apps to the same EC2 instances. Having each app's dependencies be separate from other apps has made upgrading them easier already.
This also means all containers are ephemeral and are guaranteed to be exactly the same, which is a pretty big change from our use of capistrano in practice. I'm hoping this saves us a lot of debugging hassle.
Instead of using ELBs internally, I'm using registrator to register the dynamic ports of all of my running services across the cluster in etcd, with confd creating a new template for NginX and updating it within 5 seconds if a service comes up or drops out. Apps only need to talk to their local NginX (running everywhere) to find a load-balanced pool of whichever service they are looking for. NginX is better than ELB at logging and retrying failed requests, to provide a better user-experience during things like deploys.
Some of these things could be solved by spinning up more EC2 instances. However that usually takes minutes, where docker containers take seconds, which changes the experience dramatically.
And I'm actually reducing my spend by being able to consolidate more. I can say things like "I want one instance of this unit running somewhere in the cluster" rather than having a standalone EC2 instance for it.
I'm doing this, but starting with the minimal 80MB debian:stable image and then using apt-get to grab my dependencies. The 80MB covers the dependencies for apt-get.
I believe the centos images are also minimal, but the ubuntu image starts out much larger.
Until Firefox tightens their sandbox, I believe any exploit can still use system calls to directly create TCP sockets.
Chrome forces sandboxed processes to use its network stack; if that's been configured to use Tor, it shouldn't end up revealing your IP and therefore identity.
ECMP is used heavily in serving Anycast DNS worldwide; it's only the application to HTTP that's somewhat new. A high-end router can do stateless ECMP at 10s or 100s of millions of packets per second; it's hard to find load balancers that can compete with this.
BGP has heartbeats at usually 15 to 45 second intervals depending on configuration. If BIRD stops responding, the router will withdraw its routes.
BIRD can be controlled via a Unix socket. Usually people build a health-check daemon that does queries against the local app and communicates its finding to BIRD. Working through all of the failure modes here is tricky, but doable.
The ECMP hash is often implemented as something like a CRC-16 of (protocol, source IP/port, dest IP/port) modulo the number of next-hops. I suspect the trick to keep TCP happy is to try keep the number of next-hops (shards) constant for each route.
They haven't bothered to update that page in a few years, sadly. It says "Dual Stack IPv4/IPv6 will be launched in various areas within Verizon’s FiOS network, starting Later in 2012. Check back for more information."
Password hashing algorithms make it a bit harder to guess passwords by doing thousands of iterations ("rounds") of hashing, in addition to adding a random salt to prevent creating a dictionary for common passwords.
However, e-mail addresses are generally short, human readable, and have a high probability of being at one of a handful of common domains. It would be easy to brute force your way through common e-mail address patterns at common domain names fairly quickly, if they were only protected by a single round of SHA1.
OpenSSL's benchmarking tool claims that one of my servers can do 30 million SHA1s per second given 64 bytes of input each. And we know from Bitcoin that GPUs and FPGAs can do many orders of magnitude faster than that.
How long would it take to get an arbitrary "firstname.lastname@gmail.com" given only its SHA1? The US Census reports that there are about 5,200 common first names and 89,000 common last names, for a total of around 460 million pairs or 15 seconds on my server to try all of them.
I suspect that with some heuristics to favor common e-mail address patterns, guessing at least half of a list of arbitrary e-mail addresses really wouldn't take that long.
Around 100% for anyone using the normal Tor browser bundle.
Tor is designed to hide who you are talking to, not the fact that you are using Tor. IPs and other metadata about normal Tor relays are published publicly by the network and are used by the client to build circuits through the network.
There is a special form of hidden entry node called a bridge that is designed for use in censorship-happy countries like China, but using them is a manual process that isn't the default. Traffic through bridges is a very low percentage of overall Tor usage.