Re: "No bank details" - Whoopee fucking do
It's the standard response, a bit of misdirection to make it seem better. As if bank details are the only thing that matters if there's a data breach.
30 publicly visible posts • joined 30 Jun 2009
...to 2.5-2.8 years. That's just shocking - what's wrong with you(*) all? Money to burn?
Currently running a 7 year old phone here (S5 + LineageOS) which was second-hand when I bought it. Currently on at least its third battery(**) and otherwise fully functional, although just starting to feel like it's struggling as apps gradually bloat over time.
(*) doubtless there are exceptions around here
(**) last of the Samsungs to have a removable battery
rm does, now, protect you from recursive deletes of your root FS. You have to pass it "--no-preserve-root" in order for total destruction.
https://www.gnu.org/software/coreutils/manual/html_node/Treating-_002f-specially.html
I wonder how many stressed-sysadmin-hours that feature has saved :-)
I recently discovered rclone, which has the ability to connect to onedrive, and can mount it as a filesystem. It can also stack a caching layer on top of your mount so it is tolerant of intermittent network issues e.g.on train Wi-Fi. So now I have my work onedrive mounted at ~/onedrive and can read and write files (more or less) as if they were local. Worth a look!
"the rest of the connection info, including the requested URI, is encrypted." - not quite true: SNI (Server Name Indication) leaks the hostname you're requesting as part of the TLS (HTTPS) handshake. As you say they can also infer it via the DNS lookup, but in practice they probably wouldn't do it that way.
Up to $64k now. See https://twitter.com/actual_ransom.
Still, for the time it took to write, the risk, and the fact that they don't dare actually extract the cash, the miscreants aren't gonna see a very good ROI :-)
In my last (small) company we had a couple of dozen Vaios over a few years, various models, and I recall almost all of them stopped working less than a year after warranty expiry. That is some quality manufacturing to achieve that kind of engineered-in failure rate! However, one of them was obviously sub-standard as it failed a few days *before* its warranty lapsed - took weeks for them to fix it though.
Actually the military analogy is apt. A determined attacker won't just hit the second layer of your onion and give up, they'll keep poking until they find a way though that layer. Against this form of attack, detection and response (counter-attack) are necessary. Static defences fail eventually.
To use another analogy, on your office block on a quiet industrial estate, locked doors at night aren't enough. Burglar Bill will break the window to get in. At this point your burglar alarm goes off, police respond, and all being well nothing much gets nicked (and they may even catch him). Without the detection and response, contents of locked rooms, the safe, etc. (more layers of your onion) can be breached - your entire business could vanish in the back of a transit van over a bank holiday weekend.
@Doctor Syntax: so by your highly scientific survey, pedestrians and drivers are flawless, and only some cyclists are not? I'll hazard a guess that those individuals of which you speak are dangerous/inconsiderate/oblivious more than the average, regardless of their current mode of transport, and you just notice them more when they're cycling due to your own inherent biases.
You should probably check actual statistics, which would show you that in (say) car vs. cyclist accidents the car driver is found at fault in the majority of cases.
Problem with the user+identifier@mydomain.com thing: it's a commonly known pattern, so the identifier is trivially removed or spoofed by anyone seeking to obfuscate the source of their list, or direct your attention elsewhere. So you can't really rely on it to identify the source of a leak.
If I remember correctly, way back in the early noughties when I was writing ecommerce sites and the 3-digit CVV was introduced, the instruction was that it was never to be stored anywhere in your DB, on pain of some kind of nastiness to your merchant account. I presume (but don't know) it's also not stored in a machine-readable format on the card.
Thus, the extra level of security this provides is not to turn a 16-digit number into a 19-digit one, but to guard against your card number being usable if a database where it's stored is compromised (quite likely at the time, having seen the sort of shoddy code being rushed out back then) or your card is skimmed.
So, in theory, if a card number is presented with CVV it is more likely that the person presenting it has (access to) the physical card, and less likely that they're using a card number stolen from somewhere.
I do recall having to tell coders who hadn't read the documentation that the CVV wasn't to be stored in the DB, so I'm assuming that there are various implementations out there that do store it and thus neuter it as a security measure - it's a slightly brittle solution in that respect.
I recently received an email invite from Monty to sign this petition - quite obviously a bulk mailshot. Not sure why, as the only time I recall providing my e-mail address for anything MySQL-related would be many years ago in a comment on the documentation, so presumably I have a mysql.com "account".
I was pretty pissed off TBH - if Monty is no longer part of MySQL, how is he able to get hold of this data? No unsubscribe info, unsolicited, bulk, so in my book it ticks all the boxes for being spam.
Not a great way to go about garnering support...
The asterisks stop shoulder-surfing from people reading your screen... but not watching your fingers on your keyboard. If passwords were displayed as typed, it wouldn't take long before people started looking around a little more carefully at who's watching before typing their password, instead of being lulled into a false sense of security by the fact that their password can't be seen on screen, and ignoring the fact that watching fingers is pretty easy (see AC's 70WPM comment).
However, as in many things, there is no 'one size fits all' answer. In some cases, I can see this improving security (and, as seems to have been somewhat forgotten as one of the original points of the article, usability), although in many cases it will of course not do so.