uponcoffee

Continuity. Standards and limitations keep the platform usable which makes it valuable to all involved. For walled gardens to be successful, both consumers and developers must both buy into them.

So, either people are painfully stupid or a managed platform has some appeal over free ones.

Continuity, ease of use, various warranties/guarantees make walled gardens attractive. If consumers have free reign and brick their device, it's hard to expect the manufacturer to have/honor any warranty. If developers have free reign there's no guarantee another application won't break theirs or that they won't break someone else's... or that it'll work with whatever the consumer is doing.

Yes, an obvious counter point is *nix systems, but there is some authority in that ecosystem which keeps most things working. It's still not painless to setup/use which prevents it from effectively competing with windows/Mac OS.

Simply put, the price of admission into a walled garden comes with some perks/guarantees/warranties which aren't readily available elsewhere.

It's easy to continue the line of thought to absurdity, so I leave that as an exercise to the reader.

There's a few lines here that need to be drawn somewhere. Nintendo sells access to a platform to developers. It's not unreasonable that they aren't allowed free reign to control what's run; at some point one developers free reign would conflict with anothers.

Should the consumer have free control over what's running on their hardware? Perhaps. Let's for the sake of argument assume yes.

Then how should Nintendo and third party developers deal with hackers? Completely cut their access to Nintendo/game services? Now they have a brick.

The lines drawn for developers and consumers with respect to game consoles make sense and generally work for all involved.

I think your point has legs in other contexts (i.e. Apple products, right to repair, etc) just not here. If people feel differently they should vote with their dollars, but managed walled gardens will always be greener in some aspects.

It's not fair characterize a whole community by the actions of individuals; it's just throwing around more mud.

Aside from the root comment, there is no evidence here to support the broad strokes you're making.

I think some of the sibling comments do a decent job of address the how, so I'll loop back to why.

Material science research can be expensive due to: material costs, specialized equipment, specialized knowledge, dealing with hazardous waste, facility requirements//specialization, competition over the said resources, etc.

A computational approach greatly reduces the barrier to entry and expands your reach at the same time.

Let's talk phase diagrams as an example. We have some pretty good models for calculating the phase diagrams of bulk materials, but they breakdown as we attempt to describe smaller (I.e. nano) particles. While some experimentation was/is needed to get enough raw data to model additional terms/changes that need to be applied to make the general CALPHAD approach validate at the nanoscale, we can now cheaply test theories about how size/shape/composition of nanoparticles would influence their phase diagrams.

This helps cheaply narrow and guide the search space, let's say for nanosolders, that researchers would want to follow up with physical experimentation.

This makes a loop, the resultant data is used to make better models which in turn helps point out potentially interesting systems to study.

Not to mention that css is Turing Complete.

... and then you have Javascript at the edge (e.g. Cloud flare workers, etc).

The act of circumventing tracking can ironically make you more identifiable. How many users toggle Do Not Track, how many disable Javascript and share the same user agent and ip block...

Until there are strong privacy defaults used by the masses, one has to go through ridiculous lengths to get anything more than the illusion of privacy.

Pihole's default lists and using opendns upstream is pretty solid. In my experience their databases are thorough.

My main concernsvwith these types of posts are management and defaults.

If management isn't automous, then you'll get fragmentation which becomes a fingerprinting mechanism.

If the defaults are too harsh, then you deter adoption and encourage fragmentation of those that do adopt (as they'll muck about in the config and unbreak different things).

With low adoption, using this could potentially make you more identifiable (mirroring the concern of Do Not Track as of late) , [citation needed, on mobile].

I'll definitely spin up an instance of later today, but it looks like the defaults might cause a fair bit of breakage

This ^

If it's free it's probably making money from ads, or making money from your information. Or you paid for it and it's doing the above anyways. AV style apps can ask for a lot of permissions without raising as much as an eyebrow because they need them to 'protect' users, which puts them in a nice spot to data mine.

That's a fair point. My reply was more in the context of the root comment - and with an average attacker in mind - where they were describing eavesdropping as opposed an attack carried out by a sophisticated actor.

My point was that MITMing HTTPS and HSTS isn't really necessary to carry out an attack as described by the root comment.

You only need to be in position to eavesdrop and/or MITM http connections to scrape together the necessary information; a much lower bar.

It's *not the address that matters, it's linking him to a specific LLC. If he bought his car under the same LLC that bought the house where he lives, then you can find him through the LLC.

If he used one LLC for car, another for the house, the point is moot... but the article leads me to believe they are under the same LLC, hence the initial comment.

I suppose a better question to have asked would be if there was/is any benefit for the DMV associated car+house to be purchased with an LLC rather than outright?

EDIT: a word

> When he purchased a new car, he picked a much less flashy model, and he used the L.L.C. to sign the papers.

> To register his car, the D.M.V. insisted on a real name — not an L.L.C. — and a street address.

As far as I can tell, the car belongs to the LLC, it's not in his name, but his real identity is a registered driver or some such to said car.

His real identity is tied to the DMV, which ties him to the car, which is tied to the LLC; does this not deanonymize the LLC? From the LLC you get the rest of his large assets, namely his second house.

Perhaps I'm missing something, but the DMV links him to his LLC which is linked to everything else. A quick records search on myself pulled up the requisite registration information, so I'm left to question how anonymous he actually is.

Because https mitigates their attack vectors as a mitm. They can't steal the password since it's not sent in plaintext, and for similar reasons can't deliver/inject malicious Javascript. They could collect timestamps though and scrape header information from http connections to other sites.

A nice to have but relatively unimportant feature suggestion, the option to filter by total capacity independently of drive type.

That aside, this will be useful for figuring out hosting for side projects, thank you for sharing!

You don't need to train floor employees to spot counter fits, they just need to fix ratings to enable customers to make an informed choice. Counterfeit items work because counterfeit ratings keep them promoted in search results.

Ebay works on a trust system, feedback is good/bad/neutral with a short dialogue and rolling seller ratings over a few timescales to help users guage product/seller quality. It works reasonably well.

With Amazon you need to use third party tools to filter out the bots get a similar level of information, but you have to manually wade through a bunch of bad results.