I wonder if technical complexity of implementing online age checks is about the same as implementing a robust direct democracy system - one where people can vote down bad laws instead of outsourcing those decisions wholesale to politicians they don’t even like?..
The systems which permit voting down stupid laws also permit voting down good laws. This is very "be careful what you wish for" and reductive to "the voter is always right even when they want stupid things" interpretation of democracy.
E.g. Swiss cantons opposing votes for women inside the last 2 decades.
Well, direct democracy already exists in various forms (e.g., referendums, propositions on California ballots, etc.). Sometimes bad decisions are made, but I wouldn’t call it a total disaster. Can it be improved through technical means? How much improvement would it take for it to be better than the status quo?
Because every time an account logs onto a computer, it leaves traces. Some ephemeral in memory, some permanent on disk. It can be Kerberos tickets, process tokens, domain cached credentials, hashes or even clear text passwords in memory. It's common practice in a lot of organizations for administrators to log on to random workstations to perform whatever task they need to do.
Or there is a service running in the context of a service user domain account. Or the password of the local administrator account is identical on all systems, which was very common before LAPS became a thing.
Yes, if you do everything perfectly and always go by best practices, none of this should be relevant, but most people aren't doing everything perfectly all of the time.
To access any of these things, you need local admin permissions. Then you can reuse them to log on to other systems.
Got it. So it's less about the account itself, and more about the other account data you can only acquire with admin privileges from the local machine (almost like credential stuffing)
Even if you do everything perfectly there's always a chance one of Microsoft engineers made a mistake somewhere and somebody found it and is now sitting on a zero day. And now with vibe coding the likelihood of that went up by who knows how much. Even air gapped systems get infected if the attacker is sophisticated enough.
As with the other reasons stated...
local admin, atleast in the environments I've seen, can still install software.
Installing and running something like AngryIPScanner may be possible as local admin
We may want to start thinking about smartphones as infrastructure.
It’s not practical to run five sets of power lines to each house so that utility companies can compete in a free market. Thus utility companies are heavily regulated.
But it’s also not practical for each person to carry five smartphones. So, maybe we need to regulate this space as well?..
This makes sense but is twisting the arms of the infrastructure companies the way to go? Can't we just encourage free market dynamics? If open platforms are what the consumer wants, manufacturers will sell phones with open platforms and the consumer will decide what they want to buy. EU funding can help rebalance if needed by helping develop new competitors.
EU voters decided to use regulations instead of the market. That’s their right. There’s no reason to give the market some magic position as the only way to do things.
Except people don't actually buy in a way that's consistent with enlightened self interest, making the free market at best a poor approximation to reality.
Consumers buy what's advertised, what's 'influenced', what their friends have and what's shiny, ahead of what might actually be useful for them. Micro-level decisions people make rarely take into account macro-level consequences.
This is not to say I think regulation is an amazing solution to everything, but more that I think there is a religiosity to free-market proponents that credits market participants and markets themselves with more than their due.
The free market is a myth. We have a smartphone OS duopoly, and neither one needs to provide what customers actually want in order to be successful.
A new company entering this market will have essentally no chance of being successful.
We don't have a healthy, competitive market here. If I want to buy a new couch, I have hundreds of manufacturers to choose from, with a wide variety of styles and colors. I can pretty much find my perfect couch, given enough research. And if for some reason I can't, I can hire someone to make me a fully custom couch.
Obviously furniture and phone OSes are not the same thing, and it isn't feasible to expect there would be a market for hundreds of different phone OSes. But the principle is the same.
For a team not used to code reviews, they might seem more trouble than they're worth at first. Most likely they will be more trouble than they're worth for the first few months. Keep doing them and eventually your smart developers will figure "if we have to do this anyway, we may as well find something useful to say" :)
A few things you can do to make it smoother:
- Manage expectations. Initially it may be as simple as "we just want to have a second pair of eyes on every change" or "be aware what other team members are up to" - i.e. communication first, improving code second.
- Set up your tooling to make the process smooth. If somebody wants to just get it over with - it should be easier for them to use your official review process then to use some side channel. A vicious alternative is to make using side channels harder ;)
- Leverage automation. Run tests, linters, static checkers, etc. on your PRs so that developers get something useful even if no human leaves interesting comments.
- If some team members already have experience with code reviews - adjust their workload so that they can do more reviews. They are effectively training others by example.
- Make sure that code changes under review are reasonably sized. Encourage submitting changes for review early and often. "Here is the feature I worked on for 3 months, and it's due on Friday, please review" won't make anybody happy.
- Make it less intimidating. Code reviews are not just for finding bugs and flaws, encourage reviewers to say positive things as well.
This is quite good advice, I feel the “we have to do this anyway” line is more like… “so we might as well make it easy for ourselves”… eg write code that works, you self tested it through tests and manual if needed, so the reviewer doesn’t have to get bogged down in actually running it (start by adding screenshots for this but graduate to not needing them). Keep PRs as small as possible, aka multiple PRs streaming after each other for a single feature card, get the PRs in as soon as valuable and don’t block for nitpics but the shared expectation you start to agree on things that are better and they happen with the next changes.
The general mantra being that “if it works then it shouldn’t be blocked” and developer can choose to improve the maintainability there and then or delay it to next or later PRs at their discretion. After all you trust each other.
> Leverage automation. Run [..] linters, static checkers [..]
These don't make the process smooth unless you set them up to simply give a warning rather than block the build/merge. And with that they'll likely get ignored anyway.
I think linters/etc should be avoided until you already have buy-in from the team.
It depends. If your codebase is already free of lint warnings - adding a blocking check to prevent new ones is no big deal. But if your blocking check means that everyone has to drop everything and spend a week fixing code - of course this won't be smooth.
PS. Also, it’s a good idea to have manual override for whatever autoblocks you set up. Most linters already come with this feature.
IME even better than linters is something like `go fmt` (I work mainly in Python and use https://github.com/psf/black). Rather than forcing you to manually jimmy the code to satisfy the robot, just let the robot make it look the way it wants.
> A vicious alternative is to make using side channels harder
If people are looking to side channels, that is a signal. Ignoring that, ignoring that people are trying to find ways to do their jobs effectively - I think seems to be missing the point.
> If some team members already have experience with code reviews - adjust their workload so that they can do more reviews. They are effectively training others by example.
This can backfire. Suddenly it's just a few (potentially just one or two) team members doing all of the code reviews. They feel pressure to not be the blocking part of shipping, their reviews are then done hastily. They LGTM rubber stamp stuff from the other seniors and probably punt on reviewing the other reviews until the next day. They struggle to get their own work done, 2 hours a day code reviewing is a huge impact (if reviewing work from 2 other developers, who have been jamming out code for 6, 8, 10 hours in one day - it will take 2 hours to review that the next day).
> - Make sure that code changes under review are reasonably sized. Encourage submitting changes for review early and often. "Here is the feature I worked on for 3 months, and it's due on Friday, please review" won't make anybody happy.
On the other side of the coin, "Hey, review this really quickly so I can give you a series of 4 more changes in the next two hours, before finally sending the update that does the thing."
I believe Norton Commander was the original product (for MS DOS), Midnight Commander is its open-source cross-platform clone. FAR Manager is another notable TUI clone of NC.
Windows Commander/Total Commander are also NC clones, but implemented as GUI instead of TUI.
NC was one of the most convenient UIs for managing files, it’s a pity none of the major operating systems adopted this style for their default file managers.
Volkov Commander should get an honorable mention here, it is a tiny reimplementation of the NC interface. On the FAR Manager level of complexity DOS Navigator is also notable.
The first time this happens the programmer will spend hours looking for the first few places that need to be changed. Then he will spend days debugging, and hopefully will find the last few places.
Then, even though he is now informed about the connections, he will NOT refactor this code because he (a) has no time to refactor as he already spent a week on what seemed like a one-line fix, and (b) is now terrified to touch this code any more than absolutely necessary.
> Fire and Motion, for small companies like mine, means two things. You have to have time on your side, and you have to move forward every day. Sooner or later you will win.
It's interesting to reflect on this 20 years later. Can we say that FogCreek won?..
Probably just there for legal reasons. They do mention their compensation on the site however.
> If successful, we transfer your money to you immediately. If the airline refunds your ticket within 7 days, our service is free of charge. After that, you only pay if we are successful (commission 14-28% plus VAT). For compensation claims, the commission is usually 20-30 % (plus VAT).
If it's under 7 days it's probably because the airline is just less sketchy and it's super easy for them to get the money for you. The ones that take longer are probably the ones that are a bigger pain in the butt.
