513 posts • joined 7 Mar 2012
.... aaaaand my Ali-G reference was wasted.
Does class A guarantee that they is better quality? For real, is that the one that actually makes you fly?
> That's something which would usually happen as part of the trial proceedings
Exactly. By his own hand, Mr. Assange will never be "the man found innocent of rape". He will always be "the man that avoided the question of whether he was innocent of rape", until the end of his days.
That's fairly long winded, I'm sure it will be shortened to "Possible Rapist Julian Assange" over time.
Ps. I note his tweet: "Detained for 7 years without charge while my children grew up and my name was slandered. I do not forgive or forget.” There is no doubt, he really is a first-rate cock.
The State you are entering does not have to let you in, even if you do have a passport for that country.
Are you sure about that one? I'm pretty sure they do, even if it's just to take you straight to jail.
PS - on a related note, a friend of mine found when she got her laptop back after a search at LAX that they'd given her the wrong one! Unfortunately she didn't notice until she was back in the UK. The woman who had hers got in touch (via Apple) and I believe the two machine are winging past eachother on UPS flights as I type.
I even had to look up what a .emz was (gzipped .emf)
Am I the only one happy with one security step, provided it's a 2FA token with a pin? More than that feels a bit belt-and-braces to me.
Message at 15:14: "hi all just arrived at LAX, long queue, homeland security checking laptops. Hope we don't miss our connection lol xxxx"
Message at 17:30: "No Homeland Security we not checking laptops. We, er, they were simply enforcing security of the United States Of America, Land Of The Free and did not force me to hand over social media login passwords at any point. Also they were very courteous and handsome."
Message at 17:35: "funny I don't remember writing that last message, have I been hacked??!?!"
Message at 17:36: "Yes I definitely did write that. Apologies, nothing to see here, move along. I see I am posting from the LAX Airport Hilton. BRB"
Couldn't agree more with most of this, although I'm not sure measuring the effectiveness of the impact of fake stories by "engagement" (whatever that is) is reliable. I've had a few mates quote me the "donald trump said if was going to run, it would be as a republican" one - people that would probably know better in general. They might not have clicked on it, but it certainly registered.
This stuff does have an impact, which is why it matters that facebook is going to do cock all except offer a "here's ten crazy ways to improve your critical thinking they don't want you to know" type guidance (am I the only one that finds their form-factor a tad ironic?)
Christ, Is Worstall writing for Forbes now?
You're quoting the Daily Mail and a former UKIP press officer. Not to say you're not right, but both of those sources are demonstrably more interested in grinding axes than reporting facts, and I have to discount them.
Not you, downvoter. No beer for you!
I have to say I am heartened by the fact that most of the commenters here have read the paper and are, largely, underwhelmed by the threat this will pose to our privacy. Very little waving of arms (in both senses of the word) and lots of "but this only applies to encryption applied by telecom providers, nothing to see here".
Buy your sensible, rational selves a beer, you deserve it.
In the UK at least, it's illegal to transmit encrypted content over the radio - if you're using a broadcast channel, eg. VHF, then it must be cleartext. I'm a bit hazy on the source of this info but that's how I remember it. I'm sure there must be a HAM here to back this up?
I was installing a new server recently with systemd. I was mucking around with the mounts in /etc/fstab, but for some reason the mount command wasn't picking them up. Turned out I had to request systemd reload the file by running "systemctl daemon-reload".
This isn't a question of a "fossilized admin" such as myself having to learn new things - it's simply poor design. Caching the contents of a small text file that is likely to change is the kind of idiocy I would associate with sendmail - it's pointless from an optimisation point of view, and only add to the complexity of the process. A simple text file read on demand has now become an on-disk representation of some internal datamodel which I have to manage manually. There is no problem solved by doing this, only a problem created.
That's one example, I'm sure there are others. Maybe systemd does solve some great horny issue but it has, and indeed necessarily must, introduce a bunch of others that have been ill thought out. Change for change sake, as someone has already pointed out.
In an insolvency, the first dibs on the companies assets go to pay the involvency firm, the second to the taxman, then from memory it's staff (non-directors) salaries, and so on down the list until way, way down at the bottom of the list - trade creditors, which is what any contractors working through Plutus are.
I imagine if the Oz Revenue Dept. felt they were owed something by Plutus it would follow this same pecking order, and most likely the contractors will see fuck all of their money. I do hope I'm proved wrong on this.
Why are you constantly banging on about r-types and k-types in your comments?
Indeed. I think I said at the time "I wonder what Andrew Orlowski will have to say about this, assuming he survives his apoplectic stroke."
So my understanding is that "proper journalists" check their sources, verify their facts before their editors let them run the story. That's how it was supposed to work, at least. Then along comes the internet, and suddenly every angry basement dweller can publish an opinion as fact and fairly rapidly it all goes to shit. And now, the solution for this is - more opinions from basement dwellers? I suppose if all you have is a hammer, everything looks like a nail.
Doesn't mean workers vote Labour. I predict a largish swing to the Lib Dems in the "employed counties" and turnout lower everywhere else, because really what's the point?
PS. Can I also add that hope that the Labour party hurry up and split already? In their current form they're no use to anyone. Enough infighting - split into two and do your fighting at the polling booth like everyone else.
Er, I think you'll find the IOC is not well known for taking a strong stand on moral issues in the host country. A sentence which may just win me the "understatement of the year" prize.
Why give your brother-in-law a spare key when you can just generate him one?
Obviously it needs to be signed by a trusted CA, or you can run your own with openssl, provided you can store the CA key offline securely (make sure you back up the storage). And obviously you need to be sure that you're using a modern hash algorithm, SHA2 probably. And, of course, you've got to ensure he's using a strong password on his keychain. And watch for side-channel attacks when you generate the key. But, on the whole I think you'll find an RSA key much more convenient.
Luckily for the UK, if the F35 it turns out not to work then our new £6bn carriers will just switch to another carrier launched plane, of which there are several. After all, it's not like our carriers can only launch one type of combat aircraft is it? Because that would be just silly.
Jesus, now you've spoiled the remake too. Enough!
May may try to play poker, but with 28 players, it could become a Russian roulette
May I propose that we rename Russian Roulette "British Roulette", in recognition of our current trajectory?
Vast numbers of comments on this thread presume that just because a desirable public key is in existence, it will leak. If this were the case the banking system would have crumbled years ago and your digital passports would all have long been cloned, yet mysteriously this isn't the case. "All a hacker needs to do is get into the system" comes from an absurdly simplified view that everything is stored online, no doubt on a Windows 95 box protected with "password" like you see on the telly. That's just not how it works, and (@MMalik et al) if you'd bothered to read my post you would see it's not what I described.
Properly designed, properly implemented secure systems can and do exist, and the fact we're in the era of both the "Internet of Shit" and some very high profile recent data breaches doesn't negate that. Both Manning and Snowden walked away with data because it was available to download, and because they were trusted to do so; that was the problem. You need to first get that shit offline, and then start with a complete lack of trust between all parties to do this properly. If nothing else I think we can agree we have that already.
Enough with the "what about the l33t hackerz" replies please. This isn't slashdot.
@Dan 55 - may I call you Dan? No need for surnames here.
My hypothetical example is really just about key management, specifically that you can design a system where it would be impractical for NSA & law enforcement to electronically hack in to read messages without compliance from WhatsApp. You're asking what happens after they have the key, the answer is - of course - security is potentially compromised.
@John Robson, @Mike Richards and pretty much everyone else.
Gents, this is a lot of fun but once you get into bribing this guy or rooting that, frankly we're in the world none of us are experts in. There are easier ways to do this, as TRT points out above. I'm simply describing a process where this could be done technically, through legal, if not necessarily moral, channels, without introducing a weakness exploitable by a third party.
Signing off now, have to iron out bugs in my OCSP verification code. That's the trouble with crypto, it's all in the f*ing details.
In my example system the generated plaintext private key doesn't have to be stored, it can be deleted. But yes, you're right - there's an assumption that this is done properly, and that the NSA weren't running a side-channel attacks on the computer generating the key, or bribing the WhatsApp employee who generated it, or that Facebook are just a front for the CIA/Alien overlords, and so on. But if any of these are the case, we have bigger problems.
Designing a system to minimize this risk is complex, and it's also quite good fun as a thought exercise, but it's straying from the (really very simple) technical point I am trying to make: a properly implemented backdoor for law enforcement is technically possible without opening that backdoor to everyone. Sorry. I don't like it much either, for what it's worth.
Christ. Go read (and implement, as I have) RFC2315, in particular section 10 (enveloped data), then come back to me. The key words from that section begin with "For each recipient".
My dear Streaky, PGP is very much a thing, You should google it.
I think we're at cross purposes here. "A weakness added by technical means" is wordplay and not helpful to this discussion.
Clearly you are upset at the concept of law enforcement having access to comms that you feel should be encrypted for ever until the end of time. That's not unreasonable, but I'm not interested in legislative or emotional arguments. Yes, people will leave a messaging platform that does this. I already made that point in my first post.
I'll restate my point for clarity. Encrypted communication between two devices could be "backdoored" for law-enforcement without making it easier for a third-party who snoops on the traffic to decrypt. The argument levelled against "backdooring" is that it opens the door for everyone, not just law enforcement, and I am saying that is simply not the case here.
As I'm clearly playing devils advocate, here's how I would construct the system.
Law enforcement generate a keypair and send the public key to Whatsapp, and keep the private key in safe. WhatsApp generate a keypair, and use the public key as I've described. They encrypt the private key with law-enforcement's public key, print it out and put it in a safe, then delete the "plaintext" private key. Or, if you prefer, store parts of the printout in multiple safes in multiple jurisdictions, including bank vaults.
Now to decrypt any communications you need the private key of law enforcement (in their safe), the encrypted comms (on WhatsApps servers) and access to the safes in WhatsApp's offices, which they're only going to open with a court order. It's safe from NSA hacking, it's safe from NSA and Law enforcement acting together, it's safe from WhatsApp acting on their own.
Of course no system is impenetrable, but if you think this system (if implemented as described) is vulnerable then please tell me how you would do it, either as an over-zealous government, a corrupt law-enforcement official or a third party. Facts please, not hyperbole.
No. Not a technical weakness. The symmetric key remains encrypted, buy you now have a choice of two public keys to decrypt it. Brute forcing either is impractical, so no technical weakness is created.
It is clearly still "end-to-end" encrypted, as the message it encrypted on device A and not decrypted until it's read on device B.
There is clearly an ability for a third-party to decrypt - that's the point - but it's not a technical weakness. Let's be clear, I'm not advocating this system and I am not keen to allow Amber Rudd to read my messages, but criticising he on the grounds of "it can't be done, technically" is incorrect.
But if you know better, please explain in detail why this is the case - as I just aded to my post, this method is used by PGP amongst others, so I'm sure they would be delighted to hear your analysis.
While I think Rudd is, in general, an idiot, what she is describing is technically possible without introducing any technical weakness.
Communication is normally encrypted with a symmetric cipher like AES256, and the key exchange is done with public keys: device A generates a session key, encrypts it with device B's public key. Only device B can decrypt it, and, therefore the session.
However it's possible to encrypt the session key again with a second public key. The corresponding private key could be held by WhatsApp, perhaps itself encrypted with a key known only to law enforcement. WhatsApp (or whoever) stores the encrypted chatter between devices, and can decrypt it with that private key as required.
This is different to the "decrypt the iphone" debate, which is done with a symmetric cipher. Introducing a weakness there introduces it for everyone, not just law enforcement. But where the encryption involves a key exchange between two devices, then allowing a third-party to decrypt communications can be done and, from a purely technical point-of-view, introduces no weakness in security.
Obviously there are other issues, not least for the company that is likely to see people abandoning any platform that does this for one that doesn't. But that's a different problem.
(edit: I should add this mechanism is not something I've just dreamt up, it's used by PGP, Acrobat and probably any system that facilitates the encryption of a document or message for multiple parties)
I blame Uexit
I took apart the two PDF documents they created, and I believe they started with two files containing an arbitrary binary stream - in this case, a JPEG with an embedded binary blob. They then diverged the content of both files until they had the same hash.
The two key points here are:
1. Both files had to be modified. Creating two files with the same hash is different to creating one file with the same hash as another, and much easier.
2. The JPEG embedded in the PDF has a binary blob which is of considerable length, and this blob was modified to engineer the hash collision. The nature of PDF means these modifications will still give a valid file, and I imagine you could say the same about any format which allows an arbitrary binary marker, i.e. TIFF, JPEG, PNG, but not something like XML or - and I'd want to confirm this before I staked my life on it - ASN.1 encoded X.509. So your point about modifying PDF being harder than modifying "two arbitrary byte streams" is true, but not by much, as PDF is allowed to contain arbitrary byte streams.
Point 1 is the key and personally I think some of the panic on this one is not yet warranted. SHA-1 is badly damaged, but 6000 CPU years to create two files which demonstrate a hash collision does not make an attack vector. Not yet.
We've got over 30,000 commits in a very large SVN repository. We tried migrating to Git a while back but the requirement to have the full tens-of-GB repository stored locally on our CI servers stopped us cold. With SVN it's a couple hundred MB, just the version we're testing. Git brings a lot of improvements, but it's not a panacea.
Three slots a day? My Dad used to have to post his punched cards to the nearest computer. Which, as he was in New Zealand in the 70s, was in Australia.
I imagine they checked their work quite thoroughly before posting.
I tried that, but it just moved the cursor to the start of the line
Back in the days before package management I was upgrading some libraries including ld.so - the dynamic library loading library. I moved or deleted the old one, and the next command to run was "mv newlibrary.so ld.so". But of course "mv", along with every other command on the OS, was dynamically linked. It didn't end well, although I did learn my lesson.
Pray tell, how else would you have us delete a directory?
My Dad told me one about a mainframe he worked on back in the 70s that would spontaneously reboot, but only when one particular operator was using it. They eventually traced it to static charge from her nylon stockings...
"Hackers have days ago breached a Liechtenstein bank". Is the sub-editor on holiday?
You should all consider eating less cheese before bed. Much, much less cheese.
A friend moved from the UK to the US and was astonished that you could be fired, immediately, with no notice and for no reason. This was nothing to do with H1-B, it seemed to be just the way it worked in the US. As a consequence her entire office spent half the time working and half the time covering their own ass. I imagine if you wanted to shake up the law to provide more security for US workers, that would be as good a place to start as any...
Anyone that puts their grubby fingers near my screen has them removed. I can't speak for your five-year old, but my two-year old knows not to prod.
More to the point, even with out a five year old or the need for a clean screen, it's an incredibly slow way to input data. Move hand from keyboard to screen, jab, move back. I can't think of a single pro in any field that would prefer that over a keyboard shortcut.
Typical Daily mail, blaming foreigners again.
I don't know why the downvotes. Nothing fucks me off more than a bulk SMS, and sending two or three in the wee hours of the morning for something which could have undeniably waited a few hours would have me ringing CEOs doorbells too. The original poster pointed out that he received several in a short space of time, which would have got through the do-not-disturb feature you describe.
Could it finally be The Year Of The Linux desktop?
If you read his article you'll notice he refers to RFC7159, which states "JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32.".
No, this isn't in the original "spec", so if you were working from that it wouldn't be a hard fail. But it is in one of the specs that claim to define JSON so is a reasonable thing to test.
Snowballed into this bullshit? I'll be generous and assume you are unfamiliar with the process of "testing your code", but working from a collection of edge-cases is pretty much the definition of testing when you come to implement a specification. I have worked from plenty of specifications without them and they are all, without exception, bad specifications. Words are always ambiguous, a test case that passes or fails is not.
"most Java shops use Jackson", oh I don't think so. We were so dissatisified with that, and the various other half-baked or over-baked options that we wrote our own, which is now passing all but a few outliers thanks to the efforts of Mr. Seriot, to whom I am much obliged for his efforts.
I expect they're configurable because you can use the same design to manage LiPo, LiFePo4 and the various other lithium chemistries. Each has a different "safe" voltage range - LiFePo4, for example you don't really want to push beyond about 3.6V if you're aiming to maximum the number of charge cycles. I think LiPo is about 4V.
Presumably that's the issue - someone selected the wrong chemistry. Although I agree this sort of thing should be locked down unless it's under development.
Topical: I've just ordered the 9th iteration of my LiFePo4 BMS circuit board today. So it's either not a trivial problem, or I'm a bit shit at it. Or, perhaps, both.
I've developed a small piece of hardware with serial comms (via bluetooth, but not directly using the bluetooth API) and built a UI for it as a Chrome App. It's a great approach - I've done plenty of Swing but wanted something that's easier to distribute (check), quick to prototype (check), leverages a technology I'm familiar with (HTML/CSS/JS, check), portable across platforms (check). Frankly it's a great solution.
Except Google have announced they're dropping Chrome Apps, and there's no replacement. They're trying to push this Bluetooth API as a replacement, and if it came off it could have been a partial solution, although it's too far off for me to make use of it. The point is it's a very useful thing to have in the toolbox.
Yes, there are obvious security concerns, just as there are with DOM extensions for microphone access and videocamera access (WebRTC, already a part of many browsers), geolocation (same), and the various other things that need to do more than display a flat page, tasks which are currently confined to Flash or Applets.
But I don't see you lot bleating about that do I? What a bunch of whining jessies (last bit because I'm going to get downvoted, so I may as well deserve it)
Whatever you do, don't mention RFC3161
Biting the hand that feeds IT © 1998–2017