2384 posts • joined 7 May 2012
Maybe it would help to understand if you substitute USA where you see Australia and, geez, pick any law, but let's go with DMCA, or EU and GDPR.
Our collective Muppets-in-charge can not get their head around the limits of their legislative powers.
You can ignore this unless:
(a) you planning to visit our fine shores; or
(b) you starting up a local company presence; or
(c) Some trade agreement where your own country has agreed to limit you in this area; or
(d) Your customer is subject to these laws and requires that you agree to the technical assistance measures to the extent that your law permits you to. (You are of course free to not accept such customers).
TL;DR, if you're the cow on the hill, feel free to ignore Yertle bellowing from the pond.
Re: The Holy Trinity
> They make the legislation apparently quite definite. Then subsequently they gradually widen the scope of interpretations of "terrorists, paedophiles and organised crime".
It already covers "protecting the public revenue", so add to that library/parking/dog shat on the footpath fines as technically meeting the criteria.
So your handle is quite applicable.
Sounds like you need to take more care next time you "send and e-mail" from the CEO.
"Security holes" really have gone to both extremes now. On one hand, we have exploits that rely upon timing attacks against the CPU cache to act as an oracle. But also apparently, we accidentally configured our mail server to act as a relay then spoofed an email from the PHB. HELO theregister.co.uk. Must do better.
Re: Note to self
No point if the laws of mathematics don't apply. On a serious note, do this as there are already metadata retention laws in place.
/Posted from, oooh, let's go Azerbaijan, today.
Re: WhatsApp or Signal protocol?
Why down votes for AC on a reasonable question? Signal users are indeed very interested given that WhatsApp uses the same end to end encryption protocol.
There is no need to worry that an attacker can manipulate encrypted data. This is always a possibility and is logically unpreventable (at least outside of quantum cryptography). The concerning thing is if they can do so with more than a decimal point of an astronomically small number percentage chance of detection by the receiver.
Re: But we're not going to tell you..
No-one is going to get better performance out of it. They've admitted that they will use it to cut the pie into smaller pieces rather than give users more bandwidth. Sorry, how did they put it? "double the capacity".
Re: Where does it end?
No no no. Who's on first!
what's the point anyway
Re: Ah, but
> my first harddrive was eighty whole megabytes, that's room for almost eighty floppy disks
Well lah-de-dar. Look at me and my multi megabyte scale storage nodes. We had it tough. We had to store our data on a tape using an unwound paperclip and a steady hand, magnetised by rubbing your feet on the back of a cat. But we were 'appy back then.
Re: QLC? It's not the one for me
> (Disclaimer; yes, I know some phycisist will probably come along and point out that this is misleading, inaccurate or oversimplified).
Well they can't. Not now that it has been observed.
Re: No story here
> I reckon this is gonna come in about £750-1000.
I'm guessing about the US$750-1000 range, so £750-1000 sounds about right.
We can't afford one sorry. We're too busy pulling down perfectly adequate stadiums and rebuilding ones with practically the same capacity. And let's not even get started on the powerhouse.
Maybe you could contribute to the family law fund of anyone who arrives home to a grilling about the several additional creates of
Re: 'Don't route the messenger'
> the US is about 40x the size of the UK.
Cough* Down here we have a cattle farm that is bigger than Wales.
I don't mean to single out Atlassian with this comment. Every company seems to do this, but it triggers me. It's this:
"At no point were the contents of your emails (or other data used by Jira Service Desk) exposed to other customers"
Or another way, sorry, we realised that, due to a bug, we occasionally sent some of our other customers your address and house keys, but at no point were the contents of your house exposed. We've known about this for two weeks. You should probably get new keys cut.
You cannot assert that negative. It is not knowable. I mean if your TV and jewellery turned up at said other customer's place, you could know that the keys were used. But absence of evidence isn't evidence of absence.
There's obviously a bunch of legalese in these sorts of customer communications, but sometimes I just wish that they would just explain what they know, what they don't know yet, and what is not knowable, alongside whatever action the customer can take to limit any potential harm.
Re: shit code in C# every day
> That's the reason why there could be also some Pascal-ish echoes in his later works.
That might have more to do with Anders being the original author of Turbo Pascal and chief architect at Borland for Delphi than any J++ similarity.
> boss went WFW -> ME -> Vista - > 8.x
Sorry to hear. No-one deserves that.
About a decade ago and working in a development environment old enough to order its own pint, a (former) colleague was struggling to get some application he was debugging to stop at his breakpoint. He had been through the rigmarole of doing all the pre incident steps several times and wasn't seeing the funny side of it. He finally twigged that the compiler was being too clever by half and skipping the compilation of a bunch of units that it had compiled earlier, and instead directly linked the previous build of those classes. There were no changes, except the inclusion of the debug symbols. The workaround was to make a dummy change to the file then build. Which he did, adding a message dialog to suggest that the compiler should proceed firetruck to a different location. This did the trick, the compiler stopped at the breakpoint and then the issue was resolved to everyone's satisfaction.
Fast forward a few days, the MD was demonstrating this particular feature to $IMPORTANTACCOUNT$ when a direction was displayed involving removing oneself with a firetruck.
To this day, I'd still like to know whatever dirt he held over the PHB that allowed him to not be frog marched out to the car park.
Re: Not in IT...
> surely you could just configure the linker to look in that location
Why yes you could, however that isn't the problem being solved by a library. A linker is a compile time process. It's the thing that grabs all the compiled objects and bundles them into an executable or library.
A library is something that allows you to load a library at runtime. As long as the interfaces are compatible, it means you can upgrade or replace one component without touching anything else. Symlinks allow you to install side by side versions of the same library without "DLL hell". (Different applications on a given system may require different versions of the same libraries to function. This often happens when you have a legacy application linked to an older version of a third party library together with a newer version which uses some bells and whistles not available in the old version.)
Re: They Live....
> Even if LCD does inherently produce polarised light, it doesn't stop the manufacturer turning the display 90 degrees.
That's true, but I agree with the vehicle manufacturers that a sideways mounted LCD screen is going to look a bit out of place when all the other switch gear is mounted in the upright orientation.
/Ah, my lab coat
I proudly wear my Telstra hat. I enjoy advertising their next generation CDMA network.
Re: Health Records, ok to a degree
> not some bank to assess my credit abilities because I may be too sick to pay for something
The legislators seem quite asleep at the wheel on this point. They believe that they've sorted this out with $BIGFINE$. This does not address the actual threat model.
A sufficiently big fine may have been an effective in 1983, but that assumes that they can
(1) catch them in the act, and
(2) prove that they were aware of the data misuse.
In case you are scratching your head about 2, let me outline some possibilities.
The data may be stolen in bulk via direct hack, or maybe like the publication quoted in the article, it gets accidently published (irony meter going off the scale). We have seen other government departments misconfigure their websites, resulting in the accidental leak sensitive data on asylum seekers.
Or perhaps an insider may manage to exfiltrate the data Snowdon style. It would be a courageous decision to believe that it couldn't happen.
Next step is that this data is purchased by a data aggregation company not based here. We are talking about companies paid to aggregate disparate data sources for AI training sets. That data is purchased by other aggregators, rolled together and sold on to yet others until it arrives in a company who specialises in using AI/Big data to provide risk assessment as a service to retail insurers. The retailers are at arm's length to the shadier side of the data collection. Even the risk assessment as a service don't realise that their AI training data is polluted by data obtained by questionable means. Definitely a case of don't ask don't tell.
Your AMPs of the world won't be pulling out your discussion notes from your counselor or your MRI from a decade ago. They'll just get a number out that'll be your risk band where all this is factored in. This will affect your ability to get insurance products. Computer says no. Computer says add exclusion. Computer says big loading for that inclusion.
And before anyone points out how you can investigate supply chains, remember it was only recently that Andrew Forrest discovered slavery in his supply chain. He claimed to be horrified and to have sorted it out immediately. I personally believe him. Supply chains are hard to assert. Even harder when you develop an AI that is trained to pick the datasets dynamically based on continuous "how well did it predict last week". They literally won't know why they've rejected you. Any authority charged with policing that the companies haven't misused the health data has zero chance of detecting it.
I don't see any reason why Russia would have jumped air gaps to pwn power utilities.
Re: Yay... maybe?
Anyone who is in that network path can inject, modify or suppress any of the page resources. This includes injecting coinhive.js or worse. This includes "free WiFi hotspots", and probably any hotel or airline you've ever flown. Even a major US ISP was fiddling with some headers at one point. These modifications cannot be made to a HTTPS stream unless you can convince a CA to sign your public key.
I'm not saying HTTPS is a panacea for all security ills, but I fail to see what is controversial about calling HTTP "Not Secure". It is after all, a long game of "Chinese Whispers" with no capacity to assert that what you see is what the server served or what the server sees is what you sent.
Re: It's funny to see that now...
> I mean we are long past the time when a passive attacker was a realistic scenario
It seems to me that no-one has shared this fact with a bunch of airlines, ISPs, pretty much every hotel you have ever stayed at.
I'm afraid that this is pretty close to par for the course. And you can't actually see those who just track rather than actively manipulate the traffic, but I would be amazed if it wasn't an order of magnitude greater.
Yes, TLS is imperfect because you need to trust a bunch of CAs some of which have been vaporised after spectacularly failing at their only job™, but in terms of risk management, it is night and day improvement. It's like arguing that there's no point locking your door because authorities could just open it with a carefully placed exclusive.
Companies cannot MitM a HTTPS website unless they own the computer. If they own the computer, they can just install they're own root CA, but no hotel or airline or internet cafe or ISP can do that to my device.
Re: No worries, its all good, nothing to see here....
You might as well add the 37 no sorry we mean 78 million left pondian Anthem Healthcare sods whose records were stolen by hackers in 2015. But don't worry. We have big penalties.
Re: superuser rights on the vacuum
Shirley it should be an iOS derivative? Needs to have lots of shiny.
> you will sure be regretted
That has got to be one of the best backhanded compliments that I've ever heard. I will be sure to use it on one of those oversized farewell cards that periodically frequents my desk.
> that Firefox engineers can fix
That's quite a get out of jail card ya got there.
But opt in == I approve of this message
Re: So kids, sometimes recycling is *bad*
Nonsense. All bits may be recycled. You just need to reuse them in random order.
Re: The clue is in the name
It is, but many people may not understand how it enables differential cryptanalysis. They may intuitively understand that it lowers their own security but totally misunderstand the threat model. In their minds, the risk is about whether their own message may be read, not whether they are enabling the reading of another message if the adversary holds both messages but not the key.
Re: How does Encrypted SNI protect against censorship from DNS Providers?
> Why can't China do the encryption themselves and find out what the request for a site they don't like would look like?
The way asymmetric encryption usually works is that the client would generate a random encryption key to use with a symmetric encryption algorithm (like AES). Think of this like a randomly chosen password, only with massively better entropy. This key is then encrypted with the public key (eg RSA), so only the server with the private key can derive the randomly chosen key and can then derive the content. So each request to chinadoesnotlikeme.com will look different.
So points 1 and 2 aren't a problem on this account. The real problem is knowing who owns the private key that corresponds to the public key you have just used.
> Could China block all these encrypted requests such that only standard requests get through?
They almost certainly would.
> Does China have enough power to prevent the big cloud providers from using this?
Certainly within their borders.
Re: But how?
Problematic is one way to put it. Not actually solving the elephant is another.
Censorship bypass requires that the censoring authority cannot know the private key. And if they intercept 220.127.116.11 (for example) then the public key given to the client doesn't have to be the real server's one. The terrific firewall™ can simply MitM the client hello and decide whether to drop your packets; you just used their key.
The headline implies that this is a SNI fix, whereas this solution kicks off to the never never the actual magic needed to solve it.
There's a pretty big elephant that they've managed to move if they've got this far, but I'm not following how they've solved it.
Let's rewind, why SNI? Well in HTTPS, the server needs to provide it's certificate in the serverhello message. This certificate needs to match the hostname that the client requested or it can't be trusted.
In days of old, you would bind an IP address and port to a given site, and that was how you knew which certificate to return. Port for a website was in practice restricted to 443 because no one wants colons in their URL, so you basically needed a dedicated IP address per site. That's expensive, not to mention equally easy to block undesired hosts by their IP address alone (reverse DNS lookup).
Fast forward to SNI, and the clienthello message now indicates the hostname that the server will need. Now the server can send down the right certificate, so everyone is happy, save for the fact that the clienthello is letting world+dog know about the host, and here we arrive at the elephant.
In order to encrypt, we need to either:
(a) have pre shared a key; or
(b) use the server's public key so that only that server can determine what host we want
Clearly a is out. The whole point of the TLS handshake is to get such a session key so the much faster symmetric encryption can be used (AES). So now we are talking about (b). So what is the server's public key? How can you be sure that the key provided to you doesn't belong to Mallory?
There's a hole in my bucket ....
Re: I HATE IT!!!!!11!!!111!!
No, *I* promise not to abuse it.
Re: Don't you just love it when so-called democratic governments do a public cover-up ?
Fraud!? At the ATO? Shirley not. I mean maybe one or two bad apples at the lower rungs. No-one important though. Nothing like (former) Deputy Commissioner level, that's for sure.
US voting systems (in Oregon) potentially could be hacked (11 years ago) by anybody (in tech support)
not best practice
Shirley the remote assistance platform should have been upgraded to the latest offering from that other Russian vendor.
> Don't you mean searching on Google and Stack Overflow?
I have an idea for a VS extension. You just type into a search box what you're trying to do, then it searches SO and copy pastes the accepted answer of the best matching question straight into the code.
I mean if we're going to have a process, shouldn't we automate it?
Re: Mixed Messages
And remind me who the feds sold Darwin's port to?
Re: 17713 is relatively light on features
> and they move the various system function controls around
This is the antithesis of productivity, or what you've called getting things done. I am embarrassed to admit how long it took me to get my Windows 10 laptop to connect to our work VPN. They tried to dumb it down to about 5 edits, drop-down menus and checkboxes, and in the process moved the settings that are needed behind 6 or 7 mouse clicks.
> Why do they spend so much time on Edge browser when absolutely no-one uses it?
Blatant lies. I certainly appreciate improved quality for those times when I need to download Firefox.
Re: "That was my point - the supposed stable build released"
> The problem is often features attract users more than stability
Concepts like stability* are by nature intangible. New OS supports latest VR toy? Great. New OS boots 8% faster? Awesome. New OS lasts 11% longer on batteries whilst playing 4K video stream? Nice. These are all tangible benefits where a user can decide whether they want faster boot times, longer battery life or the latest gizmos. But something that's now stable might be tangible to someone running Windows ME, anything from XP+ was never inherently unstable, at least until you started installing kernel mode webcam drivers. At scale, instability may be measurably better today, but to an individual user, they won't notice if the mean time to rebuild is a month longer than it was 3 years ago. Sad. But true.
*Substitute quality, privacy or security, it works equally well.
Re: "If the AI detects that a machine is calling you and you don't want to speak to the machine ..."
Ok, new idea.
First a countdown*.
Then a tone of about 15KHz* at maximum intensity gets blasted down the line
*Gotta have something to avoid false positives.
* We could go higher but we wouldn't want them to miss out if their hearing was down for some unknown reason.
Where's Tay when you need her?
Re: "If the AI detects that a machine is calling you and you don't want to speak to the machine ..."
I don't need an app to hang up for me. I need an app to chat with that nice but suspiciously strong accented fellow "John from Microsoft" about that pesky recurring virus that my computers always seem to get.
The evil side of me wants to compensate the said app more the longer they it can keep "John" engaged in conversation.
Re: Note to my fellow Yanks ...
All I can say is that if your in Australia and the Mrs tells you to grab a Durex, she's not going to be impressed if you return with a roll of sellotape.
Re: Smaller in the US.
Even at 2260 it doesn't sound right.
For 10 drivers, that's an average of 226L. My car has a 60L tank and it is, depending on how you define these terms, a giant SUV (right pondian) or a city car (left pondian). That is fairly typical size. The average is almost 4 tankfulls. Something isn't adding up.