Singing copyrighted Billy Joel to make your footage unusable for reality television; thanks 30 Rock for an early view into this dystopian strategy
Readit Newswcarss commented on Show HN: Stop AI scrapers from hammering your self-hosted blog (using porn) github.com/vivienhenz24/f... · Posted by u/misterchocolat
wcarss commented on EFF launches Age Verification Hub eff.org/press/releases/ef... · Posted by u/iamnothere
Okay but then if a ZKP solution is presented, that's calling their bluff. They now have one less excuse for surveillance.
EDIT: Actually do one better - tell them that for 16+ websites, you're actually protecting teenagers by keeping them anonymous.
Yeah, getting into the car with the guy holding the gun doesn't become okay because you have a great argument you're waiting to use down the road. He's already got the gun out.
We should have started arguing when he just said he had a gun, indoors, in the crowd. We shouldn't have quietly walked outside at his demand. But that all happened. Here we are now, at the car, and he's got the gun out, and he's saying "get in", and we're probably not going to win from here -- but pal, it's time to start arguing. Or better yet, fighting back hard.
Because that car isn't going anywhere we want to be. We absolutely can not get in the car right now, and just plan to argue the point later. It doesn't matter how right the argument is at all.
wcarss commented on Trillions spent and big software projects are still failing spectrum.ieee.org/it-mana... · Posted by u/pseudolus
Our reading of PCI DSS was that there was no development code in a production build. Having a --dry-run flag would have meant doing that.
You could do "here is the list of skus for transaction 12120112340112345 - run this through the system and see what you get" on our dev boxes hooked up to QA store 2 (and an old device in the lab hooked up to QA store 1). That's not a problem.
Sending the scanner reads to the current production and a dev box in production would have been a hardware challenge. Not completely insurmountable but very difficult.
Sending the keyboard entry to both devices would be a problem. The screens were different and you can hand enter credit card numbers. So keyboard entry is potentially PCI data.
The backend store server would also have been difficult. There were updates to the store server (QA store 1 vs QA store 2 running simultaneously) that were needed too.
This wasn't something that we could progressively roll out to a store. When a store was to get the new terminals, they got a new hardware box, ingenicos were swapped with epson, old epson were replaced with new (same device but the screens had to be changed to match a different workflow - they were reprogrammable, but that was something that stores didn't have the setup to do), and a new build was pushed to the store server. You couldn't run register 1 with the old device and register 2 with a new one.
Fetching a list of SKUs, printing up a page of barcodes and running it was something we could do (and did) in the office. Trying to run a new POS system in a non-production mode next to production and mirroring it (with reconciling end of day runs) wasn't feasible for hardware, software, and PCI reasons that were exacerbated by the hardware and software issues.
Online this is potentially easier to do with sending a shopping cart to two different price calculators and logging if the new one matches the old one. With a POS terminal, this would be more akin to hooking the same keyboard and mouse up to a windows machine and a linux machine. The Windows machine is running MS Word and the linux is running Open office and checking to see that after five minutes of use of the windows machine that the Linux machine had the same text entered into OpenOffice. Of course they aren't - the keyboard entry commands are different, the windows are different sizes, the menus have things in different places in different drop downs... similarly, trying to do this with the two POS systems would be a challenge. And to top it off sometimes the digits typed are hand keyed credit card numbers when the MSR couldn't get a read - and make sure those don't show up on the linux machine.
I do realize this is reminiscent of business giving a poorly spec'ed thing and each time someone says "what about..." they come up with another reason it wouldn't work. This was a system that I worked on for a long while (a decade and a half ago) and could spend hours drawing and explaining diagrams of system architecture and issues that we had. Anecdotes of how something worked in a 4M Sloc system are inherently incomplete.
Neat! Yeah, that's a pretty complex context and I completely see what you mean about the new hardware being part of the rollout and necessarily meaning that you can't just run both systems. My comment is more of a strategy for just a backend or online processing system change than a physical brick and mortar swap out.
In my note about misreading the suggestion, I was thinking generally. I do believe that there is no reason from a PCI perspective why a given production system cannot process a transaction live and also in a dry mode on a new code path that's being verified, but if the difference isn't just code paths on a device, and instead involves hardware and process changes, your point about needing to deploy a dev box and that being a PCI issue totally makes sense, plus the bit about it being a bad test anyway because of the differences in actions taken or outputs.
The example you gave originally, of shipping to the lower stake exceptional stores first and then working out issues with them before you tried to scale out to everywhere, sounded to me like a very solid approach to mitigating risk while shipping early.
wcarss commented on Trillions spent and big software projects are still failing spectrum.ieee.org/it-mana... · Posted by u/pseudolus
It's very common to use identical systems but anonymised data shipped back to test environments in such cases. There are certain test card numbers that always fail or always succeed against otherwise-real infrastructure on the card provider's side.
Absolutely, I agree that it's a useful pattern. I've personally typed 4111 1111 1111 1111 into a stripe form more times than I want to even think about.
My point above was that it's not necessarily easy to convince the operators of a business that it's a justifiable engineering expense to set up a new "prodlike but with anonymized data" environment from scratch, because it's not a trivial thing to make and maintain.
I do think it's pretty easy to convince operators of a business to adopt the other strategy suggested in a sibling thread: run a dry mode parallel code path, verify its results, and cut over when you have confidence. This shouldn't really be an alternative to a test environment, but they can both achieve similar stuff.
wcarss commented on Trillions spent and big software projects are still failing spectrum.ieee.org/it-mana... · Posted by u/pseudolus
PCI itself is Payment Card Industry. PCI DSS as noted is the Data Security Standard.
https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...
The time it was in the transition between 2.0 and 3.0 (its been refined many times since).
https://listings.pcisecuritystandards.org/documents/PCI-DSS-... is the 3.2.1 audit report template.
One of the most important things in there is you don't mix dev and production. The idea of putting a development box next to a production box that runs the same transactions... that just doesn't happen.
Failing a PCI DSS audit means hefty fines and increases of transaction fees (paying 1% more on each transaction done with a credit card can make a $10k/month - $100k/month fine a rounding error) to a "no, you can't process credit cards" which would mean... well... shutting down the company (that wouldn't be a first offense - its still not something you want to have a chat about with accounting about why everything costs 1% more now). Those are things that you don't want to deal with as a developer.
So, no. There is no development configuration in production, or mirroring of a point of sales terminal to another system that's running development code.
Development code doesn't touch other people's money. We had enough side eyes looking at the raw data for our manager's payment card on development systems because only people that banked at that local bank occasionally experienced a problem with their visa check card... https://en.wikipedia.org/wiki/Digital_card#Financial_cards - when it says "generally '^'" it means it can be some other character... and it was... and this wasn't a problem for most people, but it turned out that the non-standard separator (that we only found after reading the card's raw data) and a space in the surname would result in misparsing of the track and giving an error - but none of our other cards used a separator that didn't match the "generally").
So, being able to generate real production load (in the cafeteria) without using Visa, Mastercard, etc... was important. As was being able to fall back to using the nearly antique credit card imprinter ( https://en.wikipedia.org/wiki/Credit_card_imprinter ) for the store that was lucky to get a dozen transactions a day.
> So, no. There is no development configuration in production, or mirroring of a point of sales terminal to another system that's running development code.
This is a misreading of the suggestion, I think. My reading of the suggestion is to run a production "dry run" parallel code path, which you can reconcile with the existing system's work for a period of time, before you cut over.
This is not an issue precluded by PCI; it is exactly the method a team I led used to verify a rewrite of and migration to a "new system" handling over a billion dollars of recurring billing transactions annually: write the new thing with all your normal testing etc, then deploy it alongside in a "just tell us what you would do" mode, then verify its operation for specific case classes and then roll progressively over to using it for real.
edit: I don't mean to suggest this is a trivial thing to do, especially in the context you mentioned with many elements of hardware and likely odd deployment of updates, etc.
wcarss commented on Trillions spent and big software projects are still failing spectrum.ieee.org/it-mana... · Posted by u/pseudolus
Why not use aged/ anonymized data? This way you can use Prod data in Dev with custom security rules anonymizing your data and following DSS.
Lead: "We have six weeks to ship. Questions?"
Dev: "Could we pull an export of relevant historical data and get some time to write code to safely anonymize that, and stand up a parallel production system using just the anonymized data and replicate our deploy there, so we can safely test on real-ish stuff at scale?"
Lead: "I'll think about it. In the meantime, please just build the features I asked you to. We gotta hustle on this one."
I'm not arguing with this hypothetical exchange that it's infeasible or even a bad idea to do exactly what you suggested, but attempting to justify an upfront engineering cost that isn't directly finishing the job is a difficult thing to win in most contexts.
wcarss commented on The New AI Consciousness Paper astralcodexten.com/p/the-... · Posted by u/rbanffy
>But if it turns out that LLMs are conscious
That is not how it works. You cannot scientifically test for consciousness, it will always be a guess/agreement, never a fact.
The only way this can be solved is quite simple, as long as it operates on the same principles a human brain operates AND it says is conscious, then it is conscious.
So far, LLMs do not operate on the same principles a human brain operates. The parallelism isn't there, and quite clearly the hardware is wrong, and the general suborgans of the brain are nowhere to be found in any LLM, as far as function goes, let alone theory of operation.
If we make something that works like a human brain does, and it says it's conscious, it most likely is, and deserves any right that any humans benefits from. There is nothing more to it, it's pretty much that basic and simple.
But this goes against the interests of certain parties which would rather have the benefits of a conscious being without being limited by the rights such being could have, and will fight against this idea, they will struggle to deny it by any means necessary.
Think of it this way, it doesn't matter how you get superconductivity, there's a lot of materials that can be made to exhibit the phenomenon, in certain conditions. It is the same superconductivity even if some stuff differs. Theory of operation is the same for all. You set the conditions a certain way, you get the phenomenon.
There is no "can act conscious but isn't" nonsense, that is not something that makes any sense or can ever be proven. You can certainly mimic consciousness, but if it is the result of the same theory of operation that our brains work on, it IS conscious. It must be.
There's some fair points here but this is much less than half the picture. What I gather from your message: "if it is built like a human and it says it is conscious we have to assume it is", and, ok. That's a pretty obvious one.
Was Helen Keller conscious? Did she only gain that when she was finally taught to communicate? Built like a human, but she couldn't say it, so...
Clearly she was. So there are entities built like us which may not be able to communicate their consciousness and we should, for ethical reasons, try to identify them.
But what about things not built like us?
Your superconductivity point seems to go in this direction, but you don't seem to acknowledge it: something might achieve a form of consciousness very similar to what we've got going on, but maybe it's built differently. If something tells us it's conscious but it's built differently, do we just trust that? Because some LLMs already may say they're conscious, so...
Pretty likely they aren't at present conscious. So we have an issue here.
Then we have to ask about things which operate differently and which also can't tell us. What about the cephalopods? What about cows and cats? How sure are we on any of these?
Then we have to grapple with the flight analogy: airplanes and birds both fly but they don't at all fly in the same way. Airplane flight is a way more powerful kind of flight in certain respects. But a bird might look at a plane and think "no flapping, no feathers, requires a long takeoff and landing: not real flying" -- so it's flying, but it's also entirely different, almost unrecognizable.
We might encounter or create something which is a kind of conscious we do not recognize today, because it might be very very different from how we think, but it may still be a fully legitimate, even a more powerful kind of sentience. Consider human civilization: is the mass organism in any sense "conscious"? Is it more, less, the same as, or unquantifiably different than an individual's consciousness?
So, when you say "there is nothing more to it, it's pretty much that basic and simple," respectfully, you have simply missed nearly the entire picture and all of the interesting parts.
Why do companies attempt to prevent piracy if it doesn't hurt sales?
The opinions of their principals may not align with published findings, for many reasons.
wcarss commented on Doctor Who archive expert shares positive update on missing episode radiotimes.com/tv/sci-fi/... · Posted by u/gnabgib
wcarss commented on How to be a leader when the vibes are off chaoticgood.management/ho... · Posted by u/mooreds
Dictatorships are far more efficient.
That’s why military is a dictatorship.
That’s why “design by committee” has such a bad rep.
The only problem with dictatorships is that you can’t change them. Also countries shouldn’t fail, so an orderly “change of power” process is needed.
But you can change companies, and companies can fail.
Also, the purpose or end of a country is not to produce some widget at high efficiency for a client, or to rapidly respond to the whims of a despot. It is just a structure around the essential activity of humans simply living their lives.