kevincox

I think the attack looks more like this:

1. I log into service X with account A1 via Mullvad from country C1.

2. I log into service X with account A2 via Mullvad from country C2.

If the service wanted they can calculate how likely it is that A1 and A2 are the same WireGuard key. If you only use one exit server this probability won't be very precise. But the more exits you use the more accurate it will be even if the sets of exits are distinct between the two accounts.

If the egress IPs were assigned randomly all that service X would know is that these were both Mullvad users but the IPs alone wouldn't allow them to correlate the two users further than that.

The logic is quite simple. Management thinks that AI can improve productivity, but knows that there will be some resistance and some learning curve. So they force people to use it so that people can 1. develop their skills and workflow and 2. find out where it is useful 3. find out what needs to be improved to make it useful.

As a more obvious example consider that cars were just invented and the post office management thinks that they could improve performance of letter carriers. But right now cars are slow, break down a lot and there isn't much infrastructure for them. Lots of letter carriers will (rightly) think that it is a waste of time because they need to get in, stop, park between every house and they break down so often it isn't worth it and half of their route is unsuitable for a car anyways. But if cars are forced for a while they will find out what routes work well for cars and which don't, improve the cars and related infrastructure to make cars more effective and other improvements to unlock more productivity.

So yes, right now management is wasting money on cars and gas for no increased productivity. And yes, measuring how much gas each employee uses and encouraging to use more is obviously stupid in isolation. But the idea is to force adoption to iron out the kinks and find out where it can improve productivity. It is basically funding a research project.

The fundamental problem is that the kernel is just too huge of an attack surface. It is probably always going to have exploitable bugs. A VM (especially hardware assisted) is a relatively tiny attack surface and it shows in the amount of bugs found.

I typically say that containers (and any other isolation that shares a kernel) are good for "mostly trusted" workloads, like different teams at the same company. You want isolation against accidents more than intentional attacks.

VMs are good for just about everything if you are careful (for example what devices and hardware are exposed) but if you want ultimate isolation you want completely separate hardware. It is the only way to be sure against hardware bugs and side-channels or VM bugs.

It doesn't. All third-party contributions must assign copyright to Bitwarden.

https://contributing.bitwarden.com/contributing/

https://cla-assistant.io/bitwarden/clients

That sounds like way less of a problem than science. If you take bad sources you hurt yourself financially. For science (especially anything medicine related) you can hurt many others physically.

Yes, these are the most clearly corrupt laws that exist. It is like outlawing hammers because you may hit someone with it. It is just giving up freedom for the benefit of a few fortune 500 companies.

If any security relevant file from the host is mounted into the container this could be exploited quite easily. It is definitely a viable tool for escaping containers but it would require a bit of an attack chain and some containers may not be vulnerable.

I find models of this size (not tested this one specifically) at being very good at simple data extraction from user input. Think about things like parsing date and time of an event from a description or parsing a human-typed description of a repeating event rule.

I'm using LineageOS (which I assume is basically just ASOP) and the automatic brightness is great. I almost never touch it after about a week with the phone. I think it does some sort of basic learning. IDK if Samgsung did something worse somehow.

Kind of. It is now really just a caching proxy making it mostly useless.

Although I have found it occasionally useful for sites that have over-active bot-blocking on their feeds because Feedburner is often whitelisted.

That's a good point. Podcasts are still (almost?) exclusively RSS 2.0. IDK if this is just momentum or Apple rules but I don't think I've ever seen an Atom podcast.

But many podcast clients actually still support Atom (probably using a feed library that supports various formats?) and basically all non-podcast feed readers support Atom.

The channel pages still have auto-discovery links. So if you paste a channel URL into your feed reader it should find the feed easily.

Nah, they are both unacceptable spam. Don't put words in my mouth and don't hijack my communication for marketing.

Thanks for the link. Good to know that they are at least signed by a key. But I really like my software not changing on me at all. I'd rather have all of the modules I need locally and static.

Also creates fun situations like getting on a plane then realizing that your extension isn't available!

It seems that nixpkgs at least fails to run the extension but more by luck than design. I hope they find a way to vendor the extensions locally.

It seems that DuckDB by default downloads and runs extensions at runtime when you use certain features? This seems unnecessarily risky.

https://duckdb.org/docs/current/extensions/overview#autoload...

I would love to have more detail on this mechanism.

It can't be legal that they randomly charge extra usage with no user consent.

Yeah, it would have been a great job for an LLM. Although if you find something in the history you then need to make the annoying choice of history rewriting or just leaving it in.

As someone who released the source of an app that was always expected to be public I appreciate that it would be interesting but I'm not surprised. If the code isn't being regularly published there is just less incentive to be sure that every commit is "public ready". So when releasing I wanted to do a full review of current code (and especially comments and docs). This was tedious enough and even though we didn't find anything major and only a handful of things that should be cleaned I absolutely wouldn't want to do this for the full history.

Could we have just released it? Absolutely. But I think everyone who contributed felt better knowing that what was released had one final "ready for public" review. Then our regular review process handled that going forward.

The author seems to believe that dereferencing a null pointer is safe. DoS attacks aside dereferencing a null pointer in C++ is undefined behavior so you never know what could happen. It could easily result in bypassing seemingly unrelated security checks or any other behaviour. To know it wasn't exploitable you would need to check the compiled output of every compiler and set of flags used to compile Firefox.

This happens all of the time. It usually comes back in a few hours. But it has been very unreliable for the last week or two.

Not only on by default, it also isn't possible to disable it seems. It's forced on (other than enterprise it seems)

It is an interesting comparison that JavaScript always ensures that different evaluations of a closure expression results in unique instances. So in general the closures will require allocations for each (unless the allocation is otherwise prevented such as via escape analysis). Of course much of the underlying data may be shared, but the identity itself will be unique.

I don't know how strict JavaScript garbage collection rules are. This was non-observable for the longest time but FinalizationRegistry now exists which makes cleanup observable. It sounds like basically no guarantees are provided when an object will be cleaned up, so presumably an implementation would be allowed to make optimizations such are proposed where for PHP.

That's ridiculous. I use Git for tons of personal projects.

Why? They were promised web access. They should be able to use web access. Does the marketing say "web access for restores until 1TB" or similar?

It's possible but this seems to be quite rare. In my experience it is always just that they think a div with an onclick handler is the same thing as a link.

That is a never-ending game of whack-a-mole. There are infinite places to put command and control data.

This is why you need both. Icons are faster to recognize, but words tell you what the icons need. So you need the words at first to discover the icons, then the icons serve as valuable tools for scanning and quickly locating the click target that you are looking for.

> and have not read their own enormously detailed (and excellent) Human Interface Guidelines tomes

This seems to also apply to all new UIs produced by apple in the last 5 years.

I've also been like this. But if as the article suggests trivial options like HTML entities or elements with display:none will keep my email out of >90% of harvesters I'm reconsidering as they seem to have no downside other than an extra couple of bytes on the wire.

No browsers support streaming parsing of XHTML so you are slowing down pageloads. Especially for longer pages.

Also the ecosystem is really not there for XHTML, it never really took off. In practice it is close enough to HTML that it probably mostly works, but you are going to have problems.

The advantage is also very small, your emitter is simpler (you don't have to special case void elements and whatnot) and if you need to consume your own pages the parser is simpler. But that isn't worth much for most people.

It does make me sad, because parsing and even emitting HTML is a nightmare. But it won, so at the end of the day I find it easier to just accept that.