quacksilver

Do they include expiring credit in that figure?

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 bought a large format e-reader for the opposite reason - being able to read and study from large format textbooks while on long train journeys or in hotel rooms (or even camping). It handles stuff from arxiv fine too.

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.

If you are wasting time wording communication then are you doing it wrong?

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,

Is that not a problem with how people are using CVEs, scoring them and attaching value to them rather than whether a CVE should be assigned itself. A CVE is simply a number and some data on a vulnerability so that the community knows they are all talking about the same issue

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

From memory, online and offline transactions are usually split out by BIN number (first six digits)

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 last used a carbon imprinter in the UK in 2013. We hired out car roof boxes / cycle carriers at a summer job I had.

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.

Assume 40 inches rather than 40ft

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

There are services like vast.ai that act as marketplaces.

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

Often you will obtain a vulnerability in some software and then search for companies using it. You can often use Google or Shodan to do the searching, but perhaps ingested LLM data could also work.

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.

Would it even be possible to enumerate all edge cases and test all the permutations of them in non-trivial codebases or interconnected systems? How do you know when you have all of the edge cases?

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'

It is highly recommended to configure two or more DNS servers incase one is down.

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.

Private DNS on Android refers to 'DNS over HTTPS' and would normally only accept a hostname.

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

Sometimes devs rely on Chrome specific quirks, or are shipping broken apps that Chrome manages to make the correct guesses for it to be functional.

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.

Devs, particularly those with pressure to ship or who don't know better, unfortunately see 'it works in Chrome' as 'it works', even if it is a quirk of Chrome that causes it to work, or if they use Chrome related hacks that break compatibility with other browsers to get it to work in Chrome.

- 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.