Most of the time they have a buried clause that says that you forfeit all of your credit or get charged an inactivity fee if there have been no account transactions or no credit added for 12 or 18 months. Same reason why you should never buy gift cards.

I really like my Boox Max, as it means that I can read textbooks at a good size without reflowing. It still holds charge for several weeks at a time after about 7 years

I wish I had it at university instead of 1000+ page hardback calculus textbooks.

I imagine the response would be looking at it briefly, seeing if it looks dangerous or reproducible and getting an AI to return a templated "PoC or GTFO" response.

The mere existence of a CVE doesn't tell anyone whether a bug is valid or not, and the security reports should be handled in the same way regardless of whether one does exist. For some odd reason people have attached value to having your name logged beside CVEs, despite it not telling you anything,

Even if you need to be root to edit the files, it still is a deviation from the design or reasonably expected behaviour of that interface, so is still a bug and should still get a CVE. It should either be fixed or failing that documented as 'wont fix' and on the radar of anyone building an application. Someone building the next plesk or cpanel or similar management system should at least know about filtering their input and not allowing it to get to the dangerous config file.

Re: Harassment - Can't the project release a statement saying that the bug writeup is low quality and unable to be reproduced? Anyone ignoring that without question and using it as evidence that the project is bad without proof is putting way too much value in CVEs and the fault is their own

The BIN will tell you which bank was the issuer and which class of card you have, like standard or premium, though most readers probably don't take that into account beyond the card scheme and card type associated with the range that the individual BIN is in. Many banks will have multiple BINs for the same card type if they are large.

Credit / online debit / offline debit usually get different ranges. The reader gets a list of the ranges when it updates and they don't change super often. Offline readers can be configured to reject cards with a number in an online only range.

I am not sure how valid it was, though they would take a deposit and a card imprint until we got the car accessories back.

The offline card was from a current account with an overdraft and also worked as a cheque guarantee card, for cheques up to £250 under the (discontinued ~2011) cheque guarantee scheme[0] and had a special hologram on the back. The retailer would watch you sign the cheque and write details about you, the card and any CCTV etc. on the back of the cheque. I imagine the offline behavior of the card was similar, and was a carry over from that.

The online card was from a basic account with no overdraft facility and acted a bit like a prepaid debit card.

[0] https://en.wikipedia.org/wiki/Cheque_guarantee_card

Adding 12 meters to an aircraft is quite a big change.

You don't know who owns the GPUs / if or when your job will complete and if the owner is sniffing what you are processing though

In the simplest case if you get remote code execution in SuperServer9000 (made up product) and that has a banner on error / status pages that reads "Powered with pride by SuperServer9000 version 2.1", then you could just search for that string (or part of it) and use your remote code execution bug against any sites that come up.

It can get behavior based or more complicated than that though, or rely on information that an LLM has ingested about a company from public sources.

Then either grab data and sell it or sell your access to a broker or whatever else.

With fuzzing you can randomly generate bad input that passes all of your test cases that were written using by whatever method you have already been using but still causes the application to crash or behave badly. This may mean that there are more tests that you could write that would catch the issue related to the fuzz case, or the fuzz case itself could be used as a test.

Using probability you can get to 90 or 99% or 99.999% or whatever confidence level you need that the software is unaffected by bugs based on the input size / number of fuzz test cases. In many non-critical situations the goal may not be 100% but 'statistically very unlikely with a known probability and error'

I would count not configuring at least two as 'user error'. Many systems require you to enter a primary and alternate server in order to save a configuration.

Normal DNS can normally be changed in your connection settings for a given connection on most flavours of Android.

Many see 'it works on Chrome and mobile Safari' as 'it works' and they can get project signoff / ship / get paid / whatever and don't care about other users

The company that has the application may not know until a few users complain (if they complain) and by that point it could be too late due to the contract, or they may not understand what a different browser is or care either.

- Sometimes the standards don't define some exact behavior and it is left for the browser implementer to come up with. Chrome implements it one way and other browsers implement it the other way. Both are compatible with the standards.

- Sometimes the app contains errors, but certain permissive behaviors of Chrome mean it works ok and the app is shipped. The developers work around the guesses that Chrome makes and cobble the app together. (there may be a load of warnings in the console). Other browsers don't make the same guesses so the app is shipped in a state that it will only work on Chrome.

- Sometimes Chrome (or mobile Safari) specific APIs or functions are used as people don't know any better.

- Some security / WAF / anti-bot software relies on Chrome specific JavaScript quirks (that there may be no standards for) and thinks that the user using Firefox or another browser that isn't Chrome or iOS safari is a bot and blocks them.

In many ways, Chrome is the new IE, through no fault of Google or the authors of other browsers.

Or cooked something in a natural hot spring or natural outlet where boiling/near-boiling water forces its way to the surface.

"You can use resources (e.g. publications on Google Scholar, Wikipedia articles, interactions with LLMs and/or human experts without sharing the paper submissions) to enhance your understanding of certain concepts and to check the grammaticality and phrasing of your written review. Please exercise caution in these cases so you do not accidentally leak confidential information in the process."

From my reading then that would prohibit putting the paper into an openAI service, but how an interaction with a local LLM that doesn't involve sharing anything is treated is unclear. If you had an airgapped GPU rig running a local model and you formatted all storage on it after you were done, then no information would be shared, as you are just doing a bunch of math operations on it on your own machine.

1) Here is a new academic paper. Point out any inconsistencies, gaps or flaws in the research, and any contradictions with previous research in the field.

2) Here is a new academic paper and a journal submission policy. Does the paper meet the journal submission policy?

3) Here is a new academic paper, the review policy of the journal and a review of the paper. Does the review appear to have been conducted correctly.

4) Here is a new academic paper and a review of it. Has the review missed anything?

With the above, the reviewer could review the paper themselves, and then get the AI agent to proof read or double check everything, treating it like an editor / reviewer / secretary / grad student that they had asked to read the material. As long as the AI output was treated as potentially flawed feedback or a prompt from a third party to look deeper into something then that seems fine...

I'm surprised we are still using in-band signalling after the captain crunch whistle / blue-boxes have been around for that long

Cryptography part is fine but storage or the auth process isn't.

You would like to think that no-one would write their app that way, but there are plenty of slightly less worse things that happen in practice and vibe coding probably introduces all sorts of new silliness.