I assume he means that his GPG key is used to sign packages which get loaded to the Debian repository, which you could potentially use to upload a package with a root-executed file in it...
Further, at-rest encryption means you can't search for shit.
Yep, that's a major issue we have with the encryption technologies we use at the moment. That's where the need for homomorphic encryption and other similar searchable encryption comes from.
Almost certainly the result of someone rescuing some paper from a bin to reuse in the insulation - the notes were "destroyed" as required, but re-purposed into another process.
Agreed - I forgot that you can submit that information as part of your last tax return as well. From memory, there is a separate form for it as well, in case you leave your job on-or-before the financial year end date, but don't decide to leave the country until after you've submitted the previous year's tax return, and you don't have any income in this financial year.
But yeah, in the age-1 case you're talking about, you probably wouldn't even have a tax file number anyway...
You need slightly more understanding to go with your reading:
"Authentication" means "verification that you are talking to who you think you are talking to".
In SSH, before you send your authentication information to the server (for it to verify that it is talking to you), the server first sends it's own public key, and specific message signature with the corresponding private key. Your client checks if the public key is already known as belonging to the server (by checking known_hosts), and if not, asks if you are willing to trust the key. If you say yes, the client computes the same specific message, checks if the signature sent matches the message and public key. If this succeeds, then your client has successfully authenticated the server (verified that it is right server), and can trust that it is not a "man-in-the-middle" trying to steal your password.
After this, your client sends your authentication information to the server, and the server looks up your password in the password database, or verifies your public key, or whatever, to check your info. If this succeds, the server has authenticated your client, (verifed that your client is under your control), and can trust your client to run commands under your user id.
Not quite nothing: IIRC, you still have to file one document, once, telling the tax office that you've gone overseas, and whether it's permanent or when you're coming back.
Agreed - this makes sense if you want to display a message to the user: "The server is advertising updated host keys via the trusted channel. Do you want to add them to your local host key list?"; but automatically replacing them without prompting seems overeager...
... but anybody with a need to drive could pay the $20/gallon to drive...
That's quite a big assumption that everyone who supports the emergency surge pricing idea is making - that those who need the service will be able to afford the hugely-inflated price.
At the very least, large companies need to anticipate short-term stability, which is I think what the quote was getting at.
A small company, for which a day's takings in Bitcoin is only a fraction of the day's Bitcoin-to-local exchange volume can easily cash out immediately, and so has no need to have an expectation of long-term or short-term stability.
A large company typically cannot convert a large amount of Bitcoins to local currency instantaneously without destabilising the exchange rate, so they need to have an expectation of short-term (e.g. month-long) stability in order to manage the transaction volume against the local exchange markets.
Making (largish) loans in a currency implies expectation of decade-long stability.
He never admits that the NSA actually engineered the backdoor into the algorithm, he only states that he regrets supporting the algorithm after other people pointed out it was backdoored.
It's entirely possible that they did not engineer the backdoor - that might have come from the original creator.
It's further possible (although I would hope it's not the case) that they did not find the backdoor before it was publicly disclosed.
Either way, they should have stopped endorsing the algorithm as soon as they knew it was weak, whether that was at public disclosure or earlier.
That they continued to claim it was secure after it was publicly known to be weak is a complete failure on their part, and they are DEFINITELY culpable for that.
We BELIEVE that they probably put it there, in which case, they're even more culpable, but we don't know that for certain...
On the one hand, I agree - I know lots of people our age who don't know how to change their oil or oil filter.
On the other hand, I know many people of all ages (from 16 through 70) who don't know how to do that.
At a guess, I'd average it at about 10% in any age group who could. I'm one of the few my age; my dad is one of the few his age. Only two of my uncles or aunts could; only a couple of my cousins. A few of my friends can, but that's only because I hung out with a bunch of motorheads when I was younger...
It's Foxtel and Yahoo!7/Ninemsn/Ten, (and the other similar players) who are the instigators here.
Foxtel buys the right to show Breaking Bad and Orange Is The New Black on Australian pay TV.
Some Australian consumers choose to watch those shows on Netflix.
Foxtel loses the ability to attract those consumers, so they complain to the studios that they are losing customers that they bought (the Aussie pay TV market) because of another customer of the studios (Netflix), and threaten not to buy any new shows from the studio.
Since the agreement between the studios and Netflix stipulated that they would only show those programs in certain regions (not including Australia), the studios complain to Netflix that they are costing the studios money, and threaten not to sell any new shows to Netflix.
Netflix is forced to take action against subscribers suspected of being Australian.
And there's something really terrible about that sequence of events, but I don't know how to make it any better...
Oh and of course I use a standard user account. I have that and an admin account which is occasionally annoying with UAC but this helps and puts in another layer of security as now the payload will need to bypass this.
This one is a furphy. The ransomware runs as a low-privilege process, and encrypts your data files - which are exactly the ones your standard user account has access to overwrite. Yes, your system is protected from overwriting critical system files, but this won't stop the ransomware.
Thanks for the tip! I figured it probably could, but the debian build of NM has PolKit as a hard dep, unfortunately. Haven't got around to looking at what it would take to build from source.
In the short term, WiCD is doing 95% of what I need, so I will stick with it.
I hope to be able to contribute something useful, so will either eventually contribute a polkit-averse NM build for debian, or add MBIM support for WiCD.
Ran Debian with NM and KDE for the last couple of years as well. Purged it recently in order to remove systemd (NM depends on PolKit which depends on pam-systemd for login session management), and replaced it with WICD.
WiCD is not quite as smooth as NM for usb modems, but for wifi and wired ethernet, it does the job.
That's partly because T-Mobile is basically a European phone company - they're the international arm of Deutsche Telekom...
LEGO is contraception in its own right - just play with LEGO and you can guarantee that you're never having any kids.
I assume he means that his GPG key is used to sign packages which get loaded to the Debian repository, which you could potentially use to upload a package with a root-executed file in it...
Yep, that's a major issue we have with the encryption technologies we use at the moment. That's where the need for homomorphic encryption and other similar searchable encryption comes from.
Dan Boneh, Giovanni Di Crescenzo, Rafail Ostrovsky, Giuseppe Persiano: Public Key Encryption with Keyword Search. EUROCRYPT 2004: 506-522
Dawn Xiaodong Song, David Wagner, Adrian Perrig: Practical Techniques for Searches on Encrypted Data. IEEE Symposium on Security and Privacy 2000: 44-55
Eyal Kushilevitz, Rafail Ostrovsky: Replication is NOT Needed: SINGLE Database, Computationally-Private Information Retrieval. FOCS 1997: 364-373
Almost certainly the result of someone rescuing some paper from a bin to reuse in the insulation - the notes were "destroyed" as required, but re-purposed into another process.
"The web portion is easy, we'll get the intern to do it in a couple of weeks..."
Agreed - I forgot that you can submit that information as part of your last tax return as well. From memory, there is a separate form for it as well, in case you leave your job on-or-before the financial year end date, but don't decide to leave the country until after you've submitted the previous year's tax return, and you don't have any income in this financial year.
But yeah, in the age-1 case you're talking about, you probably wouldn't even have a tax file number anyway...
You need slightly more understanding to go with your reading:
"Authentication" means "verification that you are talking to who you think you are talking to".
In SSH, before you send your authentication information to the server (for it to verify that it is talking to you), the server first sends it's own public key, and specific message signature with the corresponding private key. Your client checks if the public key is already known as belonging to the server (by checking known_hosts), and if not, asks if you are willing to trust the key. If you say yes, the client computes the same specific message, checks if the signature sent matches the message and public key. If this succeeds, then your client has successfully authenticated the server (verified that it is right server), and can trust that it is not a "man-in-the-middle" trying to steal your password.
After this, your client sends your authentication information to the server, and the server looks up your password in the password database, or verifies your public key, or whatever, to check your info. If this succeds, the server has authenticated your client, (verifed that your client is under your control), and can trust your client to run commands under your user id.
Not quite nothing: IIRC, you still have to file one document, once, telling the tax office that you've gone overseas, and whether it's permanent or when you're coming back.
Although, in hindsight - you've already authenticated the server, so you are going to treat it as a trusted party anyway...
Agreed - this makes sense if you want to display a message to the user: "The server is advertising updated host keys via the trusted channel. Do you want to add them to your local host key list?"; but automatically replacing them without prompting seems overeager...
That's quite a big assumption that everyone who supports the emergency surge pricing idea is making - that those who need the service will be able to afford the hugely-inflated price.
At the very least, large companies need to anticipate short-term stability, which is I think what the quote was getting at.
A small company, for which a day's takings in Bitcoin is only a fraction of the day's Bitcoin-to-local exchange volume can easily cash out immediately, and so has no need to have an expectation of long-term or short-term stability.
A large company typically cannot convert a large amount of Bitcoins to local currency instantaneously without destabilising the exchange rate, so they need to have an expectation of short-term (e.g. month-long) stability in order to manage the transaction volume against the local exchange markets.
Making (largish) loans in a currency implies expectation of decade-long stability.
Also, for a tech site, this lack of comprehension is offensive:
The two halves of this sentence say exactly the same thing, but present it as two statements.
Why wait?
Samsung NX1 First Impressions Review - September 2014
Real-world test: Going pro with the Samsung NX1 - Nov 27, 2014
Samsung NX1 real-world sample images - Nov 12, 2014
Photokina 2014 Video: The Samsung NX1 - Sep 19, 2014
Enthusiast mirrorless camera roundup (2014) Samsung NX1 - Nov 27, 2014
Samsung NX1
It's entirely possible that they did not engineer the backdoor - that might have come from the original creator.
It's further possible (although I would hope it's not the case) that they did not find the backdoor before it was publicly disclosed.
Either way, they should have stopped endorsing the algorithm as soon as they knew it was weak, whether that was at public disclosure or earlier.
That they continued to claim it was secure after it was publicly known to be weak is a complete failure on their part, and they are DEFINITELY culpable for that.
We BELIEVE that they probably put it there, in which case, they're even more culpable, but we don't know that for certain...
On the one hand, I agree - I know lots of people our age who don't know how to change their oil or oil filter.
On the other hand, I know many people of all ages (from 16 through 70) who don't know how to do that.
At a guess, I'd average it at about 10% in any age group who could. I'm one of the few my age; my dad is one of the few his age. Only two of my uncles or aunts could; only a couple of my cousins. A few of my friends can, but that's only because I hung out with a bunch of motorheads when I was younger...
How about a USB sd card reader? Most of my SD cards have working write protect switches...
It's Foxtel and Yahoo!7/Ninemsn/Ten, (and the other similar players) who are the instigators here.
And there's something really terrible about that sequence of events, but I don't know how to make it any better...
I agree with most everything you said but:
This one is a furphy. The ransomware runs as a low-privilege process, and encrypts your data files - which are exactly the ones your standard user account has access to overwrite. Yes, your system is protected from overwriting critical system files, but this won't stop the ransomware.
Good catch!
Thanks for the tip! I figured it probably could, but the debian build of NM has PolKit as a hard dep, unfortunately. Haven't got around to looking at what it would take to build from source.
In the short term, WiCD is doing 95% of what I need, so I will stick with it.
I hope to be able to contribute something useful, so will either eventually contribute a polkit-averse NM build for debian, or add MBIM support for WiCD.
(And I'm working on making the usb modem use cases work more smoothly...)
Ran Debian with NM and KDE for the last couple of years as well. Purged it recently in order to remove systemd (NM depends on PolKit which depends on pam-systemd for login session management), and replaced it with WICD.
WiCD is not quite as smooth as NM for usb modems, but for wifi and wired ethernet, it does the job.
How do you attach documents to an email in a full-sandboxed world?
How do I receive a document by email, update it with my comments, and pass it along to the next reviewer?