kiallmacinnes
It's just that, sadly, we can no longer have nice things.
Doing it this way means the QR code is directly usable by consumers to get to a product info / marketing page, and directly usable by the POS systems.
Edit: I looked it up. An example URL:
https://example.com/01/09521207311511/21/1234ABDE1235
01 is a marker before the traditional barcode.
21 is a marker before the serial number.
There seems to be many other codes like 17 (expiry date) and 10 (batch number).
Compare the README.md to the skills/pay-for-http-request/SKILL.md
*Serious as in, supposed shootings / murders / kidnappings etc - not serious as in "a legitimate call out"
For me: Wifi is great! But, whenever it's practical, I avoid it... Everything with it is a tradeoff!
If the current setup can't, plugging the cameras and the NVR into a separate switch and none of that traffic will go near the rest of your LAN.
Wifi on the other hand, there's really no (practical) segregation to speak of - the spectrum has limited bandwidth, it doesn't matter if it's a different SSID / wifi network, it'll affect your Wifi!
It's definitely got home networks as a target market. It's one of the suggested use cases.
Signups typically involve agreeing to some terms, and you absolutely don't want company employees working their official job duties agreeing to random T&C's.
Minor nit - "PII" really isn't the right term to use, because it suggests the info itself must be personally identifiable to an individual. The GDPR covers much more than this, and uses the term "Personal Data".
In reality, as a service provider, you have no ability to determine if the client IP belongs to an individual or not - so you have no choice but to assume it does identify an individual.
1) Your IP address is considered personal data, as it can be used to identify you. In general, everyone can see and agree with this.
2) In the absence of additional protections and/or contract terms[1], the transfer of personal data out of the EU is an offense under the GDPR (well, technically it's not out of EU, but transfer to a country without GDPR equivalence).
So - embedding code / data from a 3rd party into your website results in a transfer of personal data.
[1] The idea of additional protections/contract terms is even questionable, but that's a whole other thing...
When a company decides to use a product, it needs to ensure that product is legal to use in their jurisdiction(s).
If it gets to a court, it's likely that the consumer/client is the claimant and the Company who chose to use US Product X is the defendant. The company who makes US Product X is likely nowhere to be seen.
I reckon this has to do with how the CI tools are configured.
Everyone knows you shouldn't commit a secret to Git, so tools like GitLab CI which require all their config be in git naturally will see less of this specific issue.
This does my nut in too - even just narrowing the Q down to modern Linux Desktops with e.g. chrome/firefox, and I have absolutely no idea what the query path is. So many components have been added to the path over the last few years :(
Using a FQDN (as in, a DNS name with the trailing dot) is the only reliable way to avoid this without breaking other things!
Continuing the example in the article, use `google.com.` and there will be just one query.
They got it back in the day (prob mid-90's) because they asked for it - IP space used to handed out like candy on Halloween.. Now that it's a valuable asset - they are very unlikely to just hand it back.
No, it's entirely unrelated to NAT. That's a consequence of the firewall on the router.
IPv6 doesn't get rid of the firewall.
The command should generally work, sure, but that doesn't appear to require the command should work for all stock package names.
I can see that argument, but - it's kinda a philosophical question about "who the sender is". Is the the person who typed out the text? or is it the server which transcribed that text into N new emails?
The ML server will verify the original authors SPF. The N recipients will verify the ML servers SPF - the chain (which matches the series of MTA's involved) is still verified end to end.
> It'll break when used together with DMARC's alignment checks.
Yea, DMARC is a much bigger issue for mailing lists, but that's no reason to say "A mailing list will _always_ break SPF" - a well configured* ML has no issues with SPF at all.
* And, yes - the definition of "well configured" had to change when SPF was introduced, that's of course annoying, but there has been many many years for ML operators to make these changes.
Nobody wants every verification resulting in a ping back to some central server doing who knows what.
e.g. some countries will consider you fully vaccinated X weeks after your 2nd jab of a specific vaccine. Others will say it's X+1 weeks.
The system has been built so that these decisions aren't in the cert itself, rather each country can layer on "business rules" on top. So - even if the cert expiry date is likely to be set far into the future, that has zero bearing on if it will be accepted or considered expired.
Lots of keyboards obviously have that already - including at least some of the Das Keyboards (mine does...)
Here's[1] the first blog I could find that at a glance appears to provide the right instructions.
[1]: https://evilmartians.com/chronicles/stick-with-security-yubi...