Re: Comments on El Reg came back to haunt me
Oh come on, you can't leave us hanging like that. We need details!!
151 publicly visible posts • joined 30 Jun 2015
To state that the 40% tax band should kick in at £70K without saying where (or if) you would raise the approx £17b in lost revenue is really pretty pointless. By way of example, if you kept the additional rate threshold at circa £125K you'd need to raise the 45% tax rate to 57% rate.
It's easy to band figures around as to what tax rates should be. It's a lot harder to balance the books!
I heard this story several (more than I care to actually state) decades ago and I was a little suspicious of it back then but here goes. To set the scene, remember that this was multiple decades ago and was at least a decade old story then.
Some benchmarks were being performed on how good the code was produced by multiple Fortran compilers (may not have been Fortran but it will serve the purpose). The code consisted of a function that simply calculated Pi to a certain number of decimal places and then quit. The test was run on a couple of compilers and the resulting code then timed as it looped around multiple times to work out the answer to the stated precision. Then another compiler was tried and the code it produced was incredibly faster. When they looked at the code, they discovered that the compiler had identified that the code had no external inputs of variables and so the outcome was completely pre-deterministic. The compiler itself ran the calculation to work out the value, and the code it produced simply set the variable to the calculated value. Job done!
Then (supposedly) yet another compiler was run that produced a tiny file that ran even faster. That compiler had identified that having calculated the value of Pi, it wasn't output to anything at all and thus the whole code was completely pointless and the program produced was simply a no-op - did absolutely nothing!
If this truly was "Pay By Bank" then either you or the rail company is severely mistaken in how it works.
When your bank asks for your "consent" you are consenting to your bank accepting the incoming payment. No more than that. Pay by Bank is push-only, and the sending party has absolutely zero access to your bank account.
What many (most?) people are missing here is that passkeys provide a significant barrier to other ways your account can be compromised. It doesn't matter how long or otherwise strong your password is, if you can be persuaded to enter that password onto a site you think is what it is but in fact is a phishing site. If that happens (and in the absence of 2FA or other security measures), your account is compromised. Likewise, if you have malware on your device that can scrape the password field or is recording your keystrokes, your account is likely to be compromised.
Passkeys - correctly implemented - solve both those. Your passkey for site <X> will refuse to authenticate on <Fake-X>. Your passkey can't be guessed or intercepted over the wire to site <X>.
Yes they are not a perfect solution but actually they solve the most likely threats other than people using ridiculously weak passwords and reusing passwords across sites.
Absolute rubbish.
With 40+ years of development across a number of technologies and having worked on, designed and built many business systems, AI can absolutely generate 100% functional code corresponding to my needs. I've been there, done that and used it. No I'm not going to use it to write an entire system but I've used it multiple times to deliver completely working functional libraries/services/factories (amend according to your language of choice) many of which consist of several hundred lines of code, saved me days worth of work, passed unit tests and now live in production systems.
I find people who rubbish AI tend to either have not used it, or not learnt how to use it well, or came to it with unreasonable expectations.
Having lived through a number of technology changes over my years on this earth, I find great similarity with both the advent of the PC and later with the advent of the internet and particularly the dot-com boom. Both of those had many people claiming it was a fad and would implode, others claiming that the world would drastically change (usually with claims that no one would have jobs)... And the truth, as always then and now with AI is somewhere in between.
My understanding is that the markets may be separate but the factories are not. Put simply, those manufacturers who make memory are switching production to where the majority demand is - thus causing a lack of supply for the consumer market - and hence prices going up for that market. As the article notes, bringing additional capacity online takes years and the historical fluctuation in prices has meant no-one has committed to building excess capacity to take advantage of times such as now.
Bad things happen. And once they've happened, how you respond is important.
I've read many a response by companies such as this to incidents such as this and, more often than not, I'm left with the feeling that I would never choose to use them in the future. The misdirection of "sophisticated attackers".. the "sorry for any inconvenience to our customers", the whole "security is our number one focus" or "our customers are important to us".
But a response such as this? OK, would prefer not to be reading it, but if it had involved me, I'd think I'd feel a little more reassured rather than less.
I'm sure it was elsewhere on the Register's forums. that I read someone who suggested that the opposite of "being woke" was "being an arsehole" and that of the two extremes, he knew which end he'd prefer to be considered as closest to.
Virtual beer (see right) for whoever posted that, as I've stolen it ever since.
Moreover, as the article itself states, earlier this month a completely innocent shopper was blacklisted due to having been incorrectly uploaded to the Facewatch database by a store who claimed she hadn't paid for something when she had - and had the receipt to prove it. So the statement that the technology "does not monitor innocent shoppers" is demonstrably false.
And then given that the completely innocent shopper was not alleged to have been violent in any way, in no way would her presence on the database protect any Iceland member of staff and clearly does not square with the statement that "It helps trained store teams calmly identify repeat offenders who are known to use violence or intimidation. That's it."
Let's be clear, this is primarily about anti-shoplifting. Not about anti-violence. It can't possibly stop someone hitting a shopworker although it might help catch and prosecute such a person after the event.
Personally I'm not 100% against use of this technology. But I am 100% against the inaccurate, false and deceptive quotes around what it does and what it is for.
I disagree. I can assimilate what 3.1m houses means - I can derive a rough figure for how many people that covers, roughly what percentage of the UK populate that represents and so forth.
But "every house in Scotland" means very little to me. I don't know how many houses there are. Being pedantic, are we talking houses or households? Are we talking about populated house(holds) or including every holiday-let, second-home and other unoccupied premises?
I'm really puzzled as to what you mean by saying "3.1m houses doesn't have any real world parallel"!! I'd have said the real world parallel was... 3.1m houses!! Can't get much more real than that, and certainly more real than a nebulous "every house in Scotland".
Indeed - I've always thought that the fact that AWS bucket names are globally unique is crazy.
There was (and is) another vulnerability reported a short while back whereby anyone finding an enumerable list of buckets such as "ABC-Client-1", "ABC-Client-2" etc, can simply go and create a bucket called "ABC-Client-99" in their own AWS account and wait to see what happens.
If AWS stuck the account number in front of the bucket name then sure you could create "ABC-Client-99" but it would be unique under your account not globally. And if you wanted anyone else to access it, you still can by just issuing the account number + bucket name and setting the appropriate permissions.
This would be the same Fujitsu employees who the Judge in the Horizon trial on 16th December 2019 stated:
I have very grave concerns regarding the voracity of evidence given by Fujitsu employees to other courts in previous proceedings about the known existence of bugs, errors and defects in the Horizon system
Hope that answers your (rhetorical) question.
But saying that you "maintain sufficient situational awareness to know if I must indicate" means that you consider yourself to be absolutely infallible, never going to make a mistake, never going to have missed something, never going to have an absolute idiot elsewhere do something silly, etc.
... which is an incredibly dangerous assumption to make.
I do remember my driving instructor many many years ago saying the same thing - "why are you indicating? Who are you indicating to?". But let me put it another way... What is the HARM in indicating? If there is a 0.000001% chance that doing so avoids an accident then surely it's worth doing unless you can demonstrate a greater chance that it causes harm?
Sure, there's a possibility that you forget to cancel the indicator (on that rare time when you indicated but didn't need to). Sure that's, annoying to other users, but it's not really causing harm. So what other harm can be caused, if you would otherwise have indicated if there was definitely a reason to?
@Missing Semicolon, have an upvote. You'd have more if I could give more.
I'm gobsmacked that anyone can genuinely say "And that's all you need". Too many developers think that it's all about them, all about the software. They have no regard for the other aspects that any sensible business needs to plan for. Like when does the training material need to get worked on? When can the sales people start selling it? When can the detailed planning start for the next project? What is the roadmap for the next 12 months? Do we need to employ more, or less, developers to handle the workload?
Any software development team or project manager who is unable to give estimates of how long it will take is quite simply failing.
@An_Old_Dog
What a complete load of rubbish. If someone asked you how long it takes to drive from Manchester to London, you'd say something like 4.5 hours. You wouldn't say, well it depends if you go via Land's End, or it depends if you have a medical emergency on the way and end up in hospital for a month before completing the journey, or that you can't say because they've not said whether they plan on driving at 1mph or 70mph.
Sure you might then go an caveat your estimate by saying there are some plausible variables which may affect things, and - if you were being helpful - you'd say that they might want to factor in perhaps an additional hour or so for some margin.
Your comment sums up everything that is wrong about the software development industry, and some of what is wrong about agile, Nobody likes the hard, detailed planning which is needed to come up with decent estimates, or the measurement needed to record how previous developments went according to their plan. Developers certainly don't want to do that (I'm generalising here), they want to start writing code at the very earliest opportunity, which is partly why agile is so popular. Of course there are unknowns, and variables which will affect things. And there are processes to accommodate and manage those. But jumping on the very first excuse and using that as to why it's impossible to come up with any estimate is ridiculous. So you've not been given all the requirements? Then estimate the ones you have. Estimate what your best guess is for the ones you don't know and explain what your margin of error is.
Can you name any other industry where your response would be considered acceptable? If you ask a builder how long it will take to add an extension to your house, you wouldn't expect him to say something along the lines of what you've put. And while I accept that many (far too many) software projects or indeed any form of engineering projects overrun, even that is no excuse for not having the plan. After all, if there is no plan, you can't say that you've overrun (hmm, and again that's another reason agile is popular), and if there is no plan, you can't improve on your estimation techniques for the next project.
But because it's hard, that doesn't mean it shouldn't be done and because it's hard, that doesn't mean that management shouldn't get told estimates.
I fail to understand your points above.
"Software is elastic"? So what? If you copy a poorly designed, bug-ridden piece of software a billion times, you now have a billion copies of a poorly designed, bug-ridden piece of software.
"Software can be delivered immediately"? If you're trying to use that as an excuse for shipping bug-ridden software ("hey, we can immediate deliver a fix") then it's a poor reason.
"Software is easy(ish) to revise (even completely)"? I disagree. I've seen many fundamental flaws in software that go right back to original design decisions and which to "fix" would basically mean starting again. I've seen small pieces of software developed in a few weeks require what would appear to be a minor bug fix which takes a significant percentage of the original development time to retrofit.
The costs of mistakes in software can be enormous. If you've got a large development team and pick up a fundamental flaw in the latter stages of development, the cost can be huge to fix. If it's discovered post-deployment then even more so (see Horizon). Ditto for "In software you can experiment for little cost".
Software Engineering is still engineering. May not be the same as other forms of engineering but then mechanical engineering isn't the same as electrical engineering. In general terms, if you're building a large, time-consuming, complex "thing" then the fundamentals of engineering apply.
Agree with the above. Moreover, if you took an average bunch of developers and ask them what they disliked about software development and then wrote up a methodology that didn't do any of those things, you'd pretty much have the Agile methodology. Developers don't like documenting things - so that's out. Working to specs - nope. Detailed estimation for the development? No, let's just focus on the next two weeks.
Agile is a methodology written by developers for developers. And unfortunately developers very often lose sight of the fact that the software is not the be-all-and-end-all, it's the use of the software, the purpose of the software, the benefit of the software that should be the focus - i.e. what the software does not how it was built that matters.
It's fine for certain types of projects. And absolutely wrong for others including, as a general broad-brush categorisation, most large business or Government type of applications. If you're a startup trying to launch your minimum viable product and then rapidly iterate, then fine, use Agile. If you're developing an ERP system or a finance/accounting/banking system, you'd better have a detailed spec, timescales, cost estimates, budgets and a clear idea of how to go about all of it.
The people who shout "Agile" from the rooftops have typically only experienced those projects that it (might be) good for and yet think that their experience encompasses all. Software development covers a huge spectrum amd in the same way that you wouldn't necessarily trust someone who can build a wall to build you a house, or trust someone who can build a house to build a skyscraper, what works or is appropriate in one place is not necessarily appropriate for another.
... coming from a software developer with 40+ years plus of bespoke development experience with a Computer Science degree before that. I've read, been taught, learned and used many different methodologies over those years, most of which promise to fix the failings of the previous one. Agile may have lasted more than some of the others, but I have no doubt that there will be another one along soon...
>> What you send is some kind of encrypted version of your password
That's not really true for 99% of all websites, at least in the way that I think you mean. Those 99% are sending your password as you typed it to the remote server although hopefully over an (encrypted) HTTPS connection. Yes, the server should then hash (not encrypt) the received password and compare against the hashed version stored in its database, but the server most certainly receives your password in the vast majority of any website (Google being an exception).
If it was as you said, then the hashing mechanism along with the salt would be visible for all to see in the client's browser making a rather large security issue. HTTPS provides sufficient encryption of your password to make it fine to send as you typed. After all, if someone was able to intercept and somehow decode your HTTPS traffic, your "encrypted version" of your password could be easily enough reverse engineered given that the encyption mechanism would be known from the front-end and thus you've not really added any additional security over the fact that your sending it over an encrypted connection.
(The above is somewhat simplistic, there are mechanisms whereby the server could pass randomly generated and time limited salt to the browser to use but that greatly complicates matters with no appreciable change to the security level.)
I believe Fogerty won ths court case didn't he? And that he then succesffuly countersued?
Furthermore the two cases against him followed the release of Centerfield were on more specific terms that just "sounds too much like CCR" - one was because one of the tracks was considered to be a personal slanderous attack on the then-owner of the rights to his previous songs and the second was on the basis that a chorus was the same (not just "sounds like") that from a previous CCR song.
For those who are using the Start Menu and typing a few characters in, can I recommend the "PowerToys Run" module from the Microsoft PowerToys.
See https://learn.microsoft.com/en-gb/windows/powertoys/run
(If anyone used to use Launchy then this is a more-or-less direct replacement/upgrade).
I have to disagree with most of what you've said.
Almost all discussion about "freedom of speech" ends up back with the American Constitution - or else you're talking purely philosophically with no definitive written word to make it anything other than a philosphical or moral debate.
As such it most certainly does relate to the government - then as to now - as it's the government that has the ability to severly restrict your personal freedoms. So no, an advertiser can not dictate what I can say in public and a government mustn't be allowed to - there is a significant different there.
You seem to conflating that difference with the ability of an advertiser to put financial pressure on a business - which is a completely different issue. An advertiser is not stating what is or isn't OK. They're saying that their money may get withdrawn and that the business may suffer, but that business is still free to do what they want. And your comment about businesses "funded by member subscription" is also far off the mark. Unless said business has a consitution requiring votes from the membership, said business is perfectly entitled to do what they want and as to whether "the majority" then walk away, that doesn't prevent that business from continuing as they please and who knows, maybe the minority is still sufficient to remain in business.
Came here to say the same thing - in response to the brief discussion about direct traffic. RSS for the win! But sadly it appears to be less and less visible (or indeed being remove) on more and more sites.
But if you have a site which publishes articles (whether a news site, or a blog,or a newsletter) and it doesn't offer an RSS feed, I'm unlikely to revisit.
In summary:
1. Lawyers typed some search request into a website
2. Website came back with some "results"
3. Lawyers took said results verbatim without checking anything
Their major failing was at step 3 and how that step was arrived at (whether AI or a *cough* reputable search engine) is pretty much irrelevant to their failing.
I agree with the above comments. Having been involved in some quite big corporate system developments, all too often companies state their requirements based on what they do. Which leads to the inability to use any off-the-shelf software as-is because it doesn't do things exactly how the company has always done things.
The answer should be to challenge how things have been done and consider whether it would be prudent to change how things are done to how the software wants things to be done. Some people will claim heresy at this point but the reality is that the bespoke development (including customisation/ehnahcement of off the shelf packages) is typically many times more complex than initially thought (often because the people who are in charge of using the system are not skilled/experienced in explaining and detailing the requirements and further more, you're left with a highly customised package, more or less beholden to continuing to use whoever the developers were who did the modifications because only they understand it, and all leading to a cost hugely more over the lifetime of the software than simply using the software off the shelf and changing one's practices accordingly.
Bespoke software is costly - from requirements capture to ongoing support. Off-the-shelf software is cheaper in the short-term and the long-term with lower maintenance & support costs and the possibility of upgrades over time.
For what should be relatively standard processes such as HR & Finance, organisations should really consider whether they have to have custom software or whether they should change their practices to conform to the software.
Of course the real failure here was on the part of the writers of the malware who, having infected 3CX software, failed to register their malware with Virus Total. If they had followed that procedure then 3CX could have easily confirmed that their software was indeed malware-infested and...
... oh wait, hang on....
>>Read the detail of the proposal again. We're talking here about a pretty narrow set of circumstances that no court of law would ever consider to cover what you're talking about.
I'm unclear from what you say as to why you seem to imply that Steve down the road has nothing to worry about. If Steve has opened an online forum then he is absolutely 100% within the scope of the legislation. And to parrot your statement, go read the legislation and it's very clear in taht regard.
Whether he may find himself in court will then be wholly dependent on what takes place in that forum. Yes, if it's all about wrongdoings of government then he's probably going to be OK. But if other matters start to be discussed, he might not sleep so well at night.
Re the supposed Fauci "lie".
I will bet my house that most people who claim he "lied" are basing this on a few-second video clip that is prevalent on... oh yes, Twitter.
I saw that clip. And I thought to myself,"that's a bit odd". And I questioned whether it might have been taken out-ot-context. I questioned whether it might have in fact been doctored (because... you know... that can happen).
So I did what any sensible, logical person would do who wants to ascertain facts.I found the transcript of the interview. Took me all of perhaps two seconds, but to save people time: https://www.msnbc.com/transcripts/transcript-all-chris-hayes-5-17-21-n1267740
And you know what? OMG he did say that!!!!
But you know what he also said in that interview? Try these quotes:
- "Breakthrough infections mean, you have been vaccinated, but you still get infected."
- "...even if you do get a breakthrough infection, when you`re vaccinated, the chances of you are transmitting it to someone else is exceedingly low."
So you know what? If he is "a liar" he's a shockingly bad one as he admitted a few seconds earlier in that same interview that, *shock horror*, you can still get infected after being vaccinated.
Was it a poor choice of words he used? Possibly. Is that quote out of context? Somewhat. Could he have been clearer? Yes.
But to call him a liar is simply ludicrous.
You use the word "haters" but I don't see any justification for the use of that word. Lots of people here are "critics" of Musk and in my opinion that's a fair stance to take.
Those that are critical of him are typically basing their opinions not on the last 2 seconds or even on just his post-buyout actions but on many years of his behaviour, comments and conduct.
In my opinion, he's a very unpleasant person. I certainly don't hate him but I will certainly criticise numerous of his activities with - again, in my opinion, but it would seem with agreement of many others - very good evidence to support me.
Brute forcing is most certainly an issue in either of your two solutions. As others have said, if you're locking the account, you've introduced an avenue for a denial of service attack and run the risk of losing all your users because they can't log in. If you do it on a backing-off approach (your second solution) then all I need to do is to cycle through my 000's of potential usernames and by the time I get back to the first, I've spent 5 seconds.
If you take into account the IP address before blocking/locking, you're not defending against botnets.
If you don't use (or enforce) long complex passwords, you're open to cracking. Salting passwords is no great defence if you suffer a breach and enough people have short passwords.
So yes, use of extra long complex passwords does indeed massively improve security. I can pretty much guarantee that my 30-char password is safe providing that the site implements what should be consider basic security even in the event of their database getting breached. I could not say the same to any degree of certainty if my password was say 8 characters no matter how complex it was.
>> "... conflating natural human beings... with business... corporations are... not natural persons"
In law - on both sides of the pond - a corporation/company is indeed a legal person and as such is far from "a legal fiction". Which makes perfect sense given that people and companies can both be libelled/defamed, sued, sign contracts, etc.
Completely agree with the above. Furthermore, I'd point out the ludicrous statement from the ruling that "... the platforms argue... a corporation's unenumerated right to muzzle speech."
As you point out the First Amendment does indeed prevent a Government from muzzling an individual. But a corporation (platform) removing comment from an individual in no way "muzles" speech - said individual is perfectly entitled to take their comment and post, or speak, or otherwise publish that anywhere else they want (that will allow them).
While I accept that a major platform banning comment does remove a large proportion of the potential audience, it is ridiculous to equate that to being muzzled.
No it doesn't mean you have to use 2FA.
Basic Auth is basically (pun intended) sending the username & password with every request.
Alternatives to Basic Auth would include schemes such as OAuth whereby a tme-limited token is used once the username & password have been authenticated.
I disagree about the possible cost of an agreed settlement.
As of today, Twitter has a capitalisation of circa $33B. Musk offered $44B.
Simplistically (very simplistically), if Musk handed over $11B to Twitter, the share price would rise to the level giving a capitalisation of what he valued the company at. Any investors then have the opportunity to sell at the price he offered and consequently there would be no case for a shareholder lawsuit.
Of course, markets don't work in such precise definable ways, so it may well take more than $11B. But I'd expect something between $11B-$20B to suffice.
Not exactly small change even for Musk (although I image the cost to his ego in settling would hurt him more), but significantly cheaper than $44B.
Except as has been proven many times over, humans are **REALLY** bad at a) looking at the URL and b) determining whether it is valid.
From mobile browsers hiding the URL, to non-Western characters in the domain to make it look right, to variations on the domain name (twilio-support.com, login-twilio.com, etc.), anyone, whether company or user, relying on reading the URL for their security is going to hit trouble.
See https://www.troyhunt.com/humans-are-bad-at-urls-and-fonts-dont-matter/ for a good write-up with examples.