Posts by Ben Tasker

> $72/year is a bit much, IMHO, considering I primarily only use it for email formy vanity domain

Yeah, pretty much my view. We use it for mail and a little bit of Drive (but I can replace that quite trivially).

My biggest concern is what happens to our Google Accounts (in the SSO sense) after - our Android devices are signed in using our AfD accounts.

Also, anything that's been purchased in Play Store will be lost - Google don't provide a way to migrate purchases over to (say) a free Gmail account, I looked into that a while back when I found that Google won't let you use Google Family Safety (or WTF it's called) with Apps for Domains accounts.

To be honest, I'm probably more likely to migrate us all over to O365 than I am to pay Google

Re: Good

The people they hit are the unwilling participants ;)

And that's before you consider whether the drivers have actually given *informed* consent.

Re: Is this a CLEAR breach?

> This is because technically the EU data subject (the website user) provided all the personally identifiable data directly to Google themselves. In effect Google is the data controller for the data the data subject handed over to Google.

No, GDPR doesn't view it that way.

That would be true if the user visited the Google analytics site in their browser, but they didn't, they went to example.at.

The operators of example.at embedded google analytics into the site, and gave the user no control/means to prevent it's use (it doesn't matter what the user could have installed in their browser, the calling site needs to provide a control)

Under your interpretation, there'd be a huge loophole, because you'd just embed JS from a third party who'd do your dodgy processing for you. The relationship exists between you (site operator) and Google, and between you and the user.

It's simpler if you view it another way: you (site operator) are using analytics, not the user. The user's data gets fed in, but it's being processed for your benefit - Google is acting on your instruction.

> I am not trying to troll with this comment, but it is important the legal system understands and clarifies such important technical facts when it is being attacked by the GDPR law.

It has - you're commenting on an article where an authority has made a decision on the matter. There may (and probably will) be a legal challenge to see if it's compliant with the regulations.

> This is equivalent to have the 3 parties in the same meeting room, having the customer recite their personally identifying data out loud. Then claiming there is a GDPR breech by the defending company, because Google wrote the information down.

Analogies are always flawed, but let's take your example anyway.

You're in a meeting with bob, Bob voices his personal details, and Charlie (from Google) writes them down, giving rise to a complaint.

- Why was Charlie in the meeting room with you?

- Did you invite him or did Bob?

If you invited him, you might be on the hook - depending on whether you could provide a good reason as to why Charlie was invited, as well as whether you met your responsibilities in terms of ensuring Charlie would handle personal data properly. For example, you could and should have exercised a control by asking Charlie to leave the room whilst personal details were dealt with.

When you get sued, you might launch your own action against Google/Charlie, but Bob's case would be with you - it's you that he has the relationship with.

You're right in that there is a loose equivalence, it just doesn't support the argument that you think it does.

Re: Rather less civil than he's used to?

> over the inclusion of an incorporated crypto payment system, when crypto users can already cut and paste a transaction into signal for the crypto network of their choice from a wallet.

I think you just highlighted the objection.

Why include it, increasing bloat and attack surface when, as you put it, it's all just "a ctl-C Ctl-v" away? As you note, it'll increase the likelihood of Signal being objected to, for what tangible gain?

Re: "prevent, in the consumer space is Auntie Mavis downloading AwesomePictures.exe"

> Probably the built-in Windows AV is enough in such case without the need to install a third party solution.

Yep, in my mind that was being castigated too as AV, but on reflection I guess it also fits into the "os-led protection" category.

Re: What if HIBP ITSELF is compromised?

> For most purposes they refer to the same process of deriving an input from an output, which once automated is functionally equivalent

> ...

> With sha1 having publicly known deficiencies (and there are likely more known privately)

Not really, you're ignoring the resources required for each, yes hashcracking is much easier nowadays, but it's still far more resource intensive than converting something. There's also the strong possibility that your input (your password) won't be derived, depending on it's strength, some luck, and the dedication of your adversary (who may be going for low hanging fruit).

Remember that collisions don't mean anything here either, in this case SHA1 isn't involved in validating passwords (it'd only matter if an adversary could find a system you'd used your password on, who were using unsalted SHA1 for storage + validation).

SHA1s known deficiencies generally relate to the ability to generate collisions (making it useless as an authentication mechanism), so aren't actually relevant here, especially as the full SHA1 doesn't hit the wire.

> The trimmed-sha looks safer but you're then stuck with a smaller subspace for your hash so you're going to get more collisions, which means more false positives.

I'm not sure you've understood how the API works...

Locally, you do

$ sha1("supersecret")

Which gives you a761ce3a45d97e41840a788495e85a70d1bb3815

You then take the first 5 chars - a761c - and send those to the API:

$ get("https://api.pwnedpasswords.com/range/a761c")

That returns a list of hash suffixes, along with the count of how often that password exists in the dataset. So, in this case, it returns 813 hashes.

0018D9D5CA61E84FA3F6CFA10F6B3418C1F:1

0166C434339B9BD3BA2A65B33612052EB36:1

01784489E12730DA0FA7F41335C7AD13D9F:60

019DA5844E6E6CA0647FA152E572B5B14E8:4

02B87026E6046E669158366E51035C63336:8

02F2E3D8176FCF4C4811AA353C513C43E67:6

02FD6B23643C3B45E07413DC31B1D1D5BAC:1

0343E72B26DCA436ECA34393CB678BACA16:3

... etc ...

You then take your prefix, bolt it back on and see if your original hash exists

In this case, "supersecret" has (unsurprisingly) been pwned quite a lot

> e3a45d97e41840a788495e85a70d1bb3815:1759

Basically, the whole point is that you *should* get a bunch of false positives back - you then filter those out as only you have the knowledge to do so.

Even if someone is able to MITM your connect (or gets hold of the API access logs):

- You've not narrowed the keyspace by very much, so they've still got to put some effort into brute-forcing

- The number of results that come back is irrelevant, as they have no way to know whether your password was included or not

Ultimately, there's an entire world of breached passwords out there - for your average adversary there's plenty of much lower hanging fruit. If you're being specifically targetted, then they're more likely to stick a RAT on your box than mess about with this.

Re: Forget technology

> 'TL:DR' blimey, you can talk, literally.

I think you've missed the point of that line...

I wasn't saying yours was too long, I was providing a TL:DR for mine, it's not an uncommon thing to do.

Normally, if someone's complaining yours is TL, then the TL:DR will be somewhere near the top of their response, not after they've been responding to points you've raised.

> Not everything is hype. Good things get overhyped but they are still good.

True, but good things also get missed amongst the hype. Given most of Web3 currently appears to be aspiration and hype, it doesn't bode well for any actual innovators lost in amongst the fog.

> Web3 is more than just crypto so you need to expand your Google searching a bit.

Funny, everything I've read says that blockchain is key to the decentralization that Web3 aims for. Blockchain relies on crypto (as in proper crypto, not digital dollars).

Of course, cryptocurrency also seems to be baked into it, even down to the idea that your reward comes in the form of a crypto-token.

It's a bit like saying that there's more to the Internet than TCP/IP - it's true, but it's pretty damn important all the same.

> Give it a go one day before you sit ringside booing the boxers claiming to be able to do better.

I think you need to check your reading comprehension - what I said was that crypto/web3 brings no benefit vs other existing solutions. I didn't claim the other solutions were better, just that a crypto-web3 is no better.

> Web3 will come whether you like it or not.

I'm sure it will, that doesn't mean it'll be good, or even an improvement. At the moment, though, there doesn't seem to be much technical substance to it.

It's not just the technicals either - Web3 "will" save us from the Web2 overlords (the distribution channels/platforms - i.e. YT, Facebook etc). Except... how are creators going to attract users? Ultimately, in the Web3 utopia, we may well end up with those same platforms dominating, just with blockchain mixed in - and that's assuming there's some kind of cutover. In reality, users will probably stay within the web2 channels, and web3 only creators will see very little.

I'm more than happy to get excited about Web3 when there's an actually viable plan involved rather than smoke and magic.

As an easy example, here's

- a Twitter thread in favour of Web3: https://twitter.com/cdixon/status/1442201621266534402

- Ethereum's page on Web3: https://ethereum.org/en/developers/docs/web2-vs-web3/

- a post not in favour: https://www.stephendiehl.com/blog/web3-bullshit.html

Note that complete lack of technical arguments/detail in the "pro" examples. They're all "this'll be better", but it's all entirely surface level. Meanwhile, "Web3 is bullshit" advances *actual* technical arguments.

You don't need to be "better" to gain adoption - sometimes the worst solution wins. What's often needed where users are concerned is convenience - Web3 has to fight against the convenience of apathy (users already in their facebook bubble, for example). But, utility is also important.

Something crypto-currency supporters seem to miss is that some of the "faults" they point to in the fiat system is actually seen as a benefit.

An easy example is the idea that there's no way to reverse a transaction:

- to cryptofolk this is good, it means there's no central authority dictating movement of your money etc

- the rest of the world looks at how many chargebacks are issued *every single day*, the protections we get from s31 etc as well as the protection we get from the bank in some circumstances

It's hard to believe that the same naivety isn't going to surface in Web3, existing as it does as a bunch of "if we say we'll build it, someone'll figure out how to"

Re: Price fixing, anyone?

Just before (as in a week) they went under, Utility Point hiked my DD to insane levels.

Then EDF went "because of higher prices, we're increasing everyone's DD by 20% for gas and 10% for Electric". Worse, because the account's not fully migrated over yet, their support couldn't do anything about it.

So I cancelled the direct debit until they can.

Still, I'm glad I didn't get sent to BG

Re: Lack of comprehension and imagination ...

> If it turns out that it's not possible to solve the problem with wind, hydro, geothermal, solar, and battery storage, sure, nuclear's the next least worst thing to add to the mix (unless I'm forgetting something). But you should probably at least work through all of those first.

Part of the problem with that, is the timeline involved in building nuclear generation capacity. By the time you realise those other options don't achieve what they promised, you're already facing a shortfall.

In fact, to a certain extent we (as a country) have already been doing what you suggest - with the result that building the capacity we need has repeatedly been kicked down the road.

Energy planning requires actual, well, planning - we should be building nuclear power stations whilst also including other technologies in the mix. If those other technologies prove themselves then you can reduce the amount of nuclear capacity you plan to build in future.

Re: Captain Obvious

> For a whole *one year* in 1996 MySQL had a rubbish product with no atomic transactions but a SQL syntax, while Postgres was a full-fledged product that favoured the far superior Quel.

You've not so much shat on his lawn as re-stated what he said.

MySQL had a market advantage for a full year and won the mindshare. It doesn't matter whether Quel was the superior solution, what matters is what the market wanted: SQL.

It's no different to Betamax/VHS, Blu-Ray/HD-DVD: it doesn't _really_ matter which is technically superior, what matters is what the market goes with. If you choose right, then you get an early leader advantage and can make it very, very hard for competitors to catch up, let alone overtake.

> Thereafter it went SQL - necessary to get market share from sheep who only knew the mantra Oracle = SQL therefore SQL = good

Or to phrase it another way - it went SQL because that was the only way to stay relevant/increase usage.

You can make hundreds of arguments over how Quel should've won out, and I'd likely agree with you, but the only thing that matters is which was chosen by the userbase.

Re: programs that run but produce the wrong result don't really fall under the "security" heading

> My view is that a bug that can reproducibly crash your machine is as much of a security issue as a bug that silently fails to check credentials correctly and that it's a category error to suggest they're inherently different things and therefore the "security" label shouldn't be applied to one and not the other.

TBH, it depends.

If you have code that

- accepts the overflow

- acts on the untrusted data

- crashes

Then you're no better offer - except in that it's a little more detectable in certain circumstances (you'll log it crashed, or a user will report it crashed)

If you have code with a stack canary thatt

- accepts the overflow

- Tries to act on the untrusted data and crashes

Then you're much better off than it being silently affected - although the underlying issue is there, you've made it harder to use it maliciously (you should, of course, still fix it).

Finally, if your code

- Accepts it

- Acts on it

- Carries on it's merry way

Then you've got the worst of both - you lack the detection vector provided by crashing out *and* would acted on the untrusted input.

All are vulnerable, two are more easily exploitable, but only one can more easily happen again, and again, unnoticed

> that it's a category error to suggest they're inherently different things and therefore the "security" label shouldn't be applied to one and not the other.

100% agree - the security label should apply to all of the above. It's a security vulnerability and needs to be addressed - the stack canary is a mitigation, not a fix.

Getting a tank into a basement is easy - at worst you just put a big hole in the floor above.

Getting a tank *out* of a basement, on the other hand, is potentially much more challenging.

Occasionally you see a news story about a bloke that's built a car/bike from scratch, often where his kitchen table used to be. They tend to have lost their wife along the way, only to find they're going to have to knock at least one one wall out of the house to get their creation out.

Someone I know very briefly had a similar experience in his garage, but that's only because we spot welded the garage door shut to wind him up (he used to go in through a side door to work on it).

Re: Perhaps a hybrid would be a better solution?

> a 5k EUR solar array can easily charge my electric car for daily needs. It's a 50k EUR car, so that's hardly a huge investment in comparison.

As an additional investment, it's another 10% on top - that's quite sizeable percentage increase. It just sounds like a small investment because one's in 10's the other's in units. If we normalise down - your car is 5000, and for solar you need to spend another 500, would you feel quite the same way?

If you got a 10% raise at work, you'd probably be delighted.

> If designed properly, these could be cheap, quiet, clear and reliable

Personally, I'm of the view that all new build developments should have on-street chargers, and a specific %age of area set aside for solar (whether that's solar on the houses, or a "communal" area feeding back into the grid, or both)

But, I also don't think it'd be cheap or reliable in practice.

> and the great thing about electric cars is they can store electricity so can be charged when it suits.

I'm not sure I follow here - my ICE car can also store energy. If I fill the tank, that fuel's still there when I come back to it.

Left long enough, petrol might go stale, but diesel doesn't *and* as far as I'm aware, you'll see a discharge rate from that leccy battery.

That's not to say there aren't other arguments for EV's, I just don't think this one is one

Re: physical harassment

Which is just as well.

If someones nutty enough to turn up with a knife over this, they'd likely just as happily turn up with a firearm if one were available.

Firearms _might_ be a deterrent for rational criminals (even that's debatable) but they do nothing for nutjobs other than to add a tool to their belt.

Re: Nominet's handing of EGM voting data to a market research agency, Savanta

> "We feel that the listening process (the project where we are seeking to get detailed feedback from members following the EGM) is a legitimate purpose for data protection law.

Data protection law also requires informed consent. It's rather hard to argue that that was obtained given that every communication from Nominet said votes were "confidential", and vote handling was out-sourced to a 3rd party (giving the impression of a secret ballot).

Re: Vi or emacs?

We always took the approach that using containers (well, specifically Docker) was fine *if* you could provide a sane justification for it.

It makes deployment much easier, sure - but in a network where deployments are relatively rare, that's outweighed by having to get the support team/ops comfortable with managing and troubleshooting Docker.

The result is that (in terms of projects) VMs have tended to be more common than containers.

Re: Erm

@codejunky

You seem to think that this suggested change in rules would result in no (meaningful) change in behaviour.

Assuming for a minute that you're right, my question would be - why waste taxpayers money drafting and enacting a bill to implement it then? If nothing changes, what exactly is the point?

FWIW, I disagree that nothing would change - it seems fairly evident that a certain category of seller would drop metric, leaving at least 2 generations of people looking at their pricing and not knowing how much they're going to end up paying.

> On who? How is it not simple to let people get on with their lives without telling them every minutia of how to interact with other people?

Entered into a computer, built on standards, submitted to a website via HTTP (also a standard) over TCP (also a standard) presumably using ethernet (wait... also a standard).

The world is built and operates on standards. When we had it, the empire enforced standards on the countries we'd stuck a flag in. Society generally works by following an agreed standard (even down to, when the light is red, don't drive your car past it).

What you actually mean, is you don't like *this rule* because you associate it with the EU, so lets get rid of it and fuck anyone that didn't grow up with pounds and ounces.

The default behaviour of Firefox when using a SOCKS proxy is to still use local DNS resolution - you have to specifically go and change network.proxy.socks_remote_dns to true if you want queries to go via your proxy.

So, this would still affect the majority of people.

Re: KDE = Kmail

> Fine as long as you remember to turn on your monitors first before waking up the computer from sleep, or your desktop orientation will randomly get borked

I don't have that, but I do have a similar annoyance.

Scenario:

- My laptop is plugged into a monitor via HDMI

- Screen locked before I wandered away (or auto locked)

- It's been left a while, so monitor has powered itself off

If I come back and waggle the mouse, then kscreenlock (or whatever it's called now) comes up prompting for my password. If I then power my monitor on, it too displays the password prompt.

Except, now, neither provides any visual feedback when I press keys to enter my password (whacking enter will unlock and everything unlocks - assuming the password's correct).

Thing is, my keyboard and mouse are plugged into a USB switch so I can switch them between machines - when it happens, I always get a hit of paranoia that I'm actually typing it into Slack/Skype on another machine

Re: “sudo su works now”

> when someone tried to install an EL7 RPM on an EL6 dev server, got a glibc error, copied over some glibc libs from elsewhere and then wondered why the server stopped working.

We had a fun one a while back - someone wanted Python 3, so forcible removed Python 2.7 (or was it 2.4)? Why, I dunno.

But, they were surprised to learn that yum relies on Python....

Re: Just ban all crypto currencies.

> as citizens no longer have to worry about how, when, why, nor even if to begin accepting crypto currencies

Personally, _if_ I was going to accept crypto I'd probably take an approach a bit like banks do during mortgage (re)valuations when there's a house price spike on.

Yes, the current "value" is $36K, but by the time I recoup there's a risk it'll be less (because the market's now not so hot), so you can buy with BTC at a rate of 1BTC = 25K.

Re: Obvious solution

> The whole point of PK encryption is that it *doesn't matter* if the public key gets intercepted.

Ahh, but it does.

As with OP, you're thinking of the wrong end.

You're right in that them intercepting the public key doesn't now mean they can decrypt message encrypted with it. But, they can substitute your PK for their PK and the other end will now be sending messages that they _can_ decrypt (and can then re-encrypt with your key to send onto you).

> In fact the normal method is to post your public key to a public forum that everyone can see, which prevents your key being substituted by someone else's public key.

It does indeed, but it also provides another path of attribution that can lead back to you. Your interactions with that public forum have to be pristinely clean, otherwise anything that links you personally to the post also links you to the key that the authorities are interested in.

It also means that you're only really moving your point of trust - has the place you've published been compromised? You could post to two places instead, but you've just doubled your potential exposure.

This headache is part of why the web-of-trust was developed - Alice trusts Bob and sign's Bob's key, Carol doesn't know Bob, but trusts Alice, therefore trust's Bob's key - that (of course) has it's own set of issues.

> Planning permission for the power station takes 10 years, it takes 5 years to build and 15 years to pay back the construction costs - even if the market for its power hadn't closed a decade earlier.

There's another "gotcha" down the line too.

You've built a bunch of power-stations to provide extra power for those D/Cs (25% of your load).

The companies behind the DCs start making noise about taxes being too high (despite IE's already bargain-basement rates). Do you

- Let them leave and swallow the cost of now having that surplus generation capacity that you're never going to need

- Give them a tax-break to keep them here, effectively delaying ROI for the power station subsidies?

I guess, though, Ireland might have a third option - we're also fucking up our own power strategy in the UK, so they could do like the French and sell us power

Re: CDN useless

Yes, even in AC's bizzare world where SSL connections are just passed through, CDN's would still offer protection against common DoS mechanisms (like SYN floods and other similar junk-at-TCP-level stuff).

What I can't work out, is why AC thinks a customer with that level of distrust would be using a CDN in the first place. Either you trust them to terminate your traffic, or you don't (and if you don't they can still do all kinds of nasty without needing your keymatter).

If you do, then you give them the means to terminate your traffic (SSL keymatter)/have them acquire their own (via LetsEncrypt or wherever). If you don't, then you shouldn't be using them.

TBH, I think AC may have confused a CDN with a router - his model seems to consist solely of forwarding packets on.

Re: Leasehold, fleecehold

The flipside of that though, is if you have a bunch of neighbours who can't/won't pay for maintenance it puts you in a sticky situation.

Do you pay out the shortfall to fix the hallway? If not, when someone falls through the floor and sues you're going to be jointly liable.

Now think about how many people you know who are either tight-fisted, or struggling financially. Really think leaving it to neighbours to sort stuff out is going to work? Nearly every private road I've driven down has been a pothole nighmare, I'm not sure extended that level of care to buildings is a wise move.

Not that the current setup is any good either.

> So what exactly is the benefit to the purchaser of these devices?

Unlike Echo and Google Home, this product has "Privacy" in the name.

That's it, that's all I can really come up with - there's no inherent privacy improvement (in fact, I'd say this has the potential to be worse as it can tell more about what you're doing).

Re: Theoretically...

> If most people were asked "do you support your data being held by an external contractor to the NHS, who only works office hours and therefore prevents the NHS from obtaining your medical data when you are in A&E in the evening or at a weekend" then the number of people in favour of retaining their information on paper with their GP would likely be less than if you listened to the concerns about data being able to be shared with other groups.

I agree with the first part, the problem is that for it to be an either-or there has to be trust.

Patients have to be able to trust that NHS Digital slurping the data will result in it being available to A&E, but going no further than that (i.e. no sharing with "other groups").

That trust has been seriously undermined by NHS Digital trying to roll out a system sharing data with "other groups" with no meaningful notice, announcement or simple way to opt-out of the slurp.

Hospitals having access is, undoubtedly, a good thing - the problem is for that to happen, NHS Digital need to have access, and it's currently impossible to trust that they won't later pass it on/sell it/leak it/otherwise screw the trust placed in them.

Admittedly, I am laying a lot of blame at NHS Digital's door here, when really there's no doubt in my mind that the Secretary of State doesn't have his fingers in this particular pie somewhere.