By adding a backdoor to E2E encryption? That is pretty much what they have been asking for :)

Amazing that criminals still pick some unknown device over an existing solution with a proven track record.

This is not the first time something like this has happened:

- https://en.wikipedia.org/wiki/EncroChat

- https://en.wikipedia.org/wiki/Sky_Global

Not really. At least in Australia's case they asked for the ability to access data on the end point while it is unencrypted, which it must be when a human consumes it. They didn't want to backdoor encryption, just bypass it. And they didn't just ask for it - they got it.

Specifically, the Assistance and Access bill (2018) [0]. The "Assistance" in the title allows them to demand assistance from a software company (eg, Google / Microsoft / Apple) in developing an app (or a modified version of an existing app) that that won't trigger the OS's warnings while it provides access to data while it is unencrypted. The "Access" in the bills title refers to the fact they can they demand the software developer force the app to be "upgraded" to the "spy" version on targeted devices via their normal security patch mechanisms.

As you can probably gather from the date of the bill, this law has been in place or about 2 years now. But it probably wasn't in place when this started, as the law was passed New Years Eve, 2018, which explains all this social engineering cloak and dagger stuff.

When I first saw the story I thought it was odd they publicising a hack that only works when nobody knows about it. But now I think about it, my guess is they publicised it because they won't need to use it again. They've legislated far easier ways to spy on a phone.

[0] https://www.homeaffairs.gov.au/about-us/our-portfolios/natio...

I don't think it's really the same as "what they were asking for" at all.

a.) they didn't compel a company to secretly do it for them

b.) the back door is targeted, I.e. not mass surveillance

As far as I understand, they did the work themselves (modified android OS), and their methods were targeted. A "bad guy" could only get this special, hacked phone, from other "bad guys". This wasn't the same thing as, sending a mole to get work at Cisco and install an undetectable zero-day in all communication infrastructure switches world-wide. And it's definitely a far cry from forcing apple to make a modified iOS on their behalf.

No, they pretty much did what hackers do, and as far as I'm concerned, that's fair game.

The problem I see with NixOS on a typical personal server is that you have to setup all these things using nix expressions, from which the actual configuration files are generated.

That means if you e.g. want to install postfix, instead of learning about main.cf you have to learn the syntax of the nix configuration wrapper for postfix, and postfix having hundreds if not thousands of options, many referring to external files/databases, you have to hope that whoever did this configuration wrapper, supported all the features of postfix that you want to use.

I am using nixpkgs on macOS, and I run a personal server with mail (for a bunch of people), web (for a bunch of sites), DNS (for a bunch of domains), etc. and while I would love to switch to declarative configuration, I fear I would run into shortcomings with the configuration wrappers for the various software packages I use.

I am curious if anyone have experience to share?

lots of services defined in the NixOS options will have an "escape hatch" option named something like `extraConfig`. this usually lets you append verbose text to a complex config file, like in the case of Postfix where the options couldn't conceivably cover everything.

you can also always just write a static file to /etc if you want or need to:

    environment.etc.foo-config = {
      target = "foo.conf";
      text = ''
        enable_spline_reticulator = true
      '';
    };

    systemd.services.foo = {
      after = [ "network-online.target" ];
      wantedBy = [ "multi-user.target" ];

      serviceConfig = {
        ExecStart = ''
          ${pkgs.foo}/bin/food \
            --config /etc/foo.conf
        '';
        User = "foo";
        Restart = "on-failure";
      };
    };

another useful escape hatch is that you can run Docker/Podman containers declaratively. I have some things I want the flexibility to upgrade on a different cadence than NixOS itself (such as my family's "production" Jellyfin server) that I just run as standalone Docker containers with volume mounts for their data.

From a quick search, it seems you can use `services.postfix.config` and pass key-value pairs as arbitrary options. Not familiar with this service, but usually if a given one has more complex syntax, there is a “pass-through” option that will simply append to the given config file whatever text you provide, as well as as the sister reply says you can create manually additional files.

And then there is the re-use of things between services, for example DKIM’s generated public key should be made available as a TXT record by the DNS server, the SSL certificate kept up-to-date by the web server should be used by both the smtp and imap servers, though it may need to include the full chain, and services may need to be relaunched, if the certificate is updated, etc.

I was hoping to hear from someone who had managed to get a “full” server running (with SMTP, IMAP, DKIM, DNS, DNSSec, HTTPS via ACME, etc.), because while I know that I can output raw configuration files, it seems like an extremely daunting task to weave all this together in something semantically meaningful.

Right now I have /etc under git control and a Makefile that handles all dependencies between the various pieces (i.e. to ensure proper files are regenerated/indexed as needed, and services relaunched when dependencies are updated).

With one exception (nginx, because it's very well supported) I always just use raw config files and ignore the options. For TVL[0] we've written a bunch of NixOS modules[1] ourselves where the upstream one was either not flexible enough, or deviated strongly from how we wanted things to work.

Nix is the kind of tool that lends itself well to solutions that are more complicated than the problem, but once you get comfortable with the tool it's easy to sidestep that. Despite these warts it's 100% worth the investment.

[0]: https://code.tvl.fyi/about/

[1]: https://cs.tvl.fyi/depot/-/tree/ops/modules

I think a better solution (long-term) is actually a redesigned way of doing service declarations where we're dealing with composable bits of data that describe services (so that a module isn't all-or-nothing anymore). Too much on the plate to design that though ...

It depends on the topic/domain, but I have fond memories of being on various mailing lists, and there was also usenet.

I don't think of the developer eras as pre-SO vs post-SO, more pre-Google vs post-Google, though SO has definitely been a net positive.

The Danish strategy is to test a lot of people and catch new cases early.

Requiring a green corona passport when entering various establishments where transmission can happen, is both a way to decrease the chance of transmission in these places, and to force more people to get tested, to hopefully catch asymptomatic people before they infect too many other people.

The reopening is possible because of previous actions, and its result will only be seen in a few months.

I would argue it’s actually a sub-zero-sum game because the “game master” (bitcoin miners) withdraw 12.5 coins from the pool every 10th minute.

What you store is your private key.

Your private key was generated together with your public key, and your public key is, well, public.

So the question is, can someone re-generate your private key?

In theory, yes, it is possible. In practice, it takes a very very long time.

But sometimes flaws are found in the generation process, like a weak pseudo-random number generated used, which significantly reduces the solution space, and then it becomes feasible.

So yes, it does matter if we let financial institutions disregard risk in the pursuit of profit, when they are gambling with other people’s money.

In the case of Tether though, it’s not a traditional bank that issues interest yielding loans based on the lender’s credit profile.

Rather, the suspicion has been that they are simply issuing USDT coins to buy up crypto, which causes the latter to increase in value, but the money to buy these assets were never there in the first place, and that is why today, they can only show a fraction of the cash they claim to have received.

"As announced on March 15, 2020, the Board reduced reserve requirement ratios to zero percent effective March 26, 2020. This action eliminated reserve requirements for all depository institutions."

I experienced time very differently the past year. I thought it was two years already. But I'm sure there was another announcement similar to that earlier.

Edit: another poster linked the actual Fed announcement and it is actually 1 year since the reserve requirement has been lifted.

Changing reserve requirements is part of conventional monetary policy, it is not QE.

And for what? There is no way Apple can make it impossible to get malware notarized.

Some people (are they the minority? probably?) cut release builds frequently enough for it to be a big pain point.

> and so you have to sign in and accept an agreement - [which isn't] a big deal

It probably is though. Have _any_ agreements you've accepted in the last, say, 5yrs not had blatantly overbearing or malicious terms?

Signing the agreement is also not just clicking “Agree”, you have to hunt for the contract online first. Last time I did this, their 2FA was down, so just logging in took me about a minute.

It feels like a lot of friction that serves absolutely no purpose, which makes it so extremely infuriating.

This is from the same company whose former CEO pressured a developer to reduce the boot time of the Macintosh (and got a 28 second speedup).

Yes, this stuff really matters to a lot of us!

For example will a lawmaker holding a large portion of their wealth in Apple shares want to introduce legislation that forces Apple to allow alternative app stores (costing Apple the 15%-30% cut of all the app store sales)?

The issues that arise are then a question about how to translate them to journal entries, which will require accounting experience, and maybe your chart of accounts needs to be revised, but the core system should be fairly stable, and voiding an invoice by issuing a credit note comes automatically, as you’re working with an append-only ledger.

The issues about prepaid plans should also be handled, as payments for services not rendered yet should not be recognized as income, but instead kept as a liability: The OP mentions their system is used by 15,000 customers, so I would give each customer their own account (in the chart of accounts).

The main technical issue is what datatype to use for money, the rest are problems solved by following general accounting principles, though I fear that a lot of programmers out there are reinventing the wheel (in suboptimal ways).

This entirely depends on whether you are operating on a cash or accrual basis. Both approach are valid (at least in the USA) and cash basis is often used by small businesses.

Though the IRS does limit the types of businesses that can do cash-basis accounting, it would be businesses without inventory, and who does not offer credit to their customers, e.g. a hairdresser would probably use cash-basis accounting, but more complicated businesses would not, certainly not a business that needs its own billing system :)

I fumbled and bumbled my way to this realization while trying to build a billing system intended to tolerate all sorts of invoicing and reversal scenarios.

More precisely, it doesn't matter what the nature of the billing is, ie recurring (monthly, quarterly..etc) vs one-time; You want to build a system around invoicing for discrete items and resolving those invoices against various criteria (payment received, credits issued, cancelled plans...etc).

I've built a billing system for a hosting platform. Back when all I knew was MVC (and the then common index.php ballofmud). I wish I had known about eventsourcing then, because so many problems that I spent weeks on, would have never occurred, or been solved in hours.

Eventsourcing comes with its own downsides, requires your mindset to change (esp hard in a team that has been doing relational databases or MVC for years), and is convoluted. But it is a very good fit for a large swath of problems. Financial ones the most.

I believe double entry accounting can be described as following this architectural pattern (despite predating it with hundreds of years).

Double entry accounting has both a ledger and a journal. The ledger describes the actual transactions, the journal groups multiple transactions and assigns a “why”, it can also link the journal entry to an invoice, receipt, credit note, or user who caused the journal entry to be created.

So the journal is your event log (not the ledger).

> Eventsourcing comes with its own downsides, requires your mindset to change

Similar to double entry accounting: The learning curve I would say is the “chart of accounts”, how to express everything as ledger transactions, be it tax, fees, discounts, credits, prepayments, etc.

But it can all be done, and once you understand the system, it becomes trivial and extremely flexible.

A rule of thumb is that any number in the interface should come from the ledger, e.g. if you issue an invoice and give your customer a discount, there must be a ledger entry corresponding to that discount.

How hard can it be???

<goes away and starts writing a new javascript framework from scratch that addresses precisely _one_ of the billing scenarios, and depends on 17,000+ npm libraries, including leftpad.js>