The tendency for infection is correlated to how popular the OS is, goes the oft-repeated idea.
For relative infectibility, I quote the "exposed to malware" numbers from the article. They make it a little ambiguous whether this means actual infections. And for relative popularity between Windows OSs, I quote from the Wikipedia article on Windows (with some averaging).
"Exposed To Malware"
XP - 41%
Vista - 38%
7 - 16%
(Relative) Install Base
XP - 46%
Vista - 11.4%
7 - 40.2%
Appears to be a large discrepancy between these numbers. Any explanations? On the face of it it looks like it is not true that popularity of OS correlates highly with infection rate.
What I'd like to see is a protocol for handling all the social interactions that Facebook provides. Then folks could write apps and servers to implement it. Technically-minded nerds could run their own servers. Other folks could just choose whichever provider they pleased, much like selecting mail or web hosting.
My browser has Perspectives and Certificate Patrol. This way I know if other network locations are seeing the same cert that I'm seeing, and whether that cert's changed recently.
Technological advance is the purview of many, not only technophiles, academics, or governments. Technology to monitor and correlate just advances. Other than that, I agree with you.
More data goes online every day, even aside from what we put there ourselves, data sourced a myriad ways, ways multiplying constantly. It's a(n ever more) digital life.
There's no pulling the plug. There's only learning to cope. It's just fact that our lives, the lives of everyone, grow ever more transparent.
I was wondering whether there were some damage potential from capsaicin.
Capsaicin is a highly irritant material requiring proper protective goggles, respirators, and proper hazardous material handling procedures.In cases of skin contact (irritant, sensitizer), eye contact (irritant), ingestion, and inhalation (lung irritant, lung sensitizer). Severe over-exposure to pure capsaicin can result in death; the lethal dose (LD50 in mice) is 47.2 mg/kg.[52] [57]
Painful exposures to capsaicin-containing peppers are among the most common plant-related exposures presented to poison centers. They cause burning or stinging pain to the skin, and if ingested in large amounts by adults or small amounts by children, can produce nausea, vomiting, abdominal pain and burning diarrhea. Eye exposure produces intense tearing, pain, conjunctivitis and blepharospasm.[58]
But my question is, how much of this software will see the light outside the universities?
Impossible to answer. What defines a serious project versus someone's pet project or proof of concept? Then of those, how do you measure success? How many Sourceforge projects "see the light" outside Sourceforge?
Is there any list of successful software created entirely inside universities' labs that became widely used?
This is the question you seem to be getting an answer to in the forum here. Hopefully it helps.
Tor uses OpenSSL's "empty fragment" feature, which inserts a single empty TLS record before every record it sends. This effectively randomizes the IV of the actual records, like a low-budget TLS 1.1. So the attack is simply stopped.
"More Powerful than" and "better at" here mean "lend themselves conveniently to such tasks in the given context (of the command line)".
Yes, for file handling, launching commands, and for simple inter-process communication shells — all shells, not just bash — are far more convenient than Python or Perl.
Don't fire off grep when you fire off ps (which you did by piping to grep) — do your grep after the ps completes. O=`ps -ef`;echo "$O"|grep bluefish|awk '{print $2}' O=`ps -ef`;echo "$O"|awk '{/bluefish/ print $2}'
If you're not actually looking for something on the command line, don't print whole command lines, just the commands. ps without flags. ps|awk '/bluefish/ {print $1}'
Specify to ps the executable command you wish ps to show you. ps -C bluefish|awk '/bluefish/ {print $1}
And output only its PID (and hide output headers). ps -C bluefish -o "pid" --no-headers
the only way to truly learn unix commands and get comfortable with command line tools is to avoid the UI completely.
That doesn't sound quite right. I did personally learn most of my basic command line skills in a windowing-free environment, but I don't think it's necessary.
I think that even after 20 years of command line experience I could learn new things. Regardless of running X.
never know when you need those command line skills again
See, this is a weird idea, too. That command line skills might come in handy. I use the command line every day. Maybe you use some kind of file management app like Windows Explorer? I file manage through the command line. Probably not the most efficient way (I never did learn tools like Midnight Commander), but the command line works well enough.
But the most interesting part of Miller's Dart memo is his rationale. As he sees it, the competition isn't about Dart versus JavaScript or any other language, for that matter; it's about nothing less than the Web versus "compelling alternative platforms" -- platforms, he says, such as Apple's iOS.
Increasingly, consumers have two ways to access the Internet and Web-based information services. Many still do it the traditional manner: through a Web browser. But a growing number of consumers are turning to smartphones as their primary means of accessing those services, and their window to the Web is not the mobile browser, but purpose-built smartphone apps.
What are the ways in which HTML/CSS+JavaScript is not an effective platform v. native apps? What can be done about it?
Is this the reason that open source software developers are so 'enthusiastic' about their products while the general market resists them – because those proponents had a hand in developing them?
This "decentralized SSL Observatory" idea is fantastic. The notaries paradigm we've been discussing (Perspectives, Convergence) requires multiple views for efficacy, the more the better (within certain parameters). I'd been imagining a system in which individuals could opt to be notaries/cert reporters, and this is a step in that direction. Now the EFF could turn into a nexus for thousands and thousands of views. Of course they'd aggregate those thousands of views into a single point of failure, but that's okay, you'd only be using the EFF as one notary in your council of many. There are plenty of other trustworthy organizations who could run their own notaries based on similar methods or otherwise effective methods. I expect even individuals will run their own notaries, much as they run Tor servers or even NTP or SMTP.
I didn't say it was perfect, my point here is that in a worst case situation, a CA system still can work acceptably, even if not in an user friendly manner or using the default settings.
If we're getting down to the level of manually removing CAs, there's a lot of security inconvenience that's "acceptable".
... I'm advocating for multiple signatures
That would certainly be an improvement.
And did you know that Diginotar's website had been hacked as far back as 2 years ago?
I see the same problem existing with notaries, except worse, because notaries will be much less monitored.
Notaries are different from CAs.
If any one CA tells you a site is good, your browser says it's good. So if any one CA fails, your security is broken. And in a bad way. A false positive way.
If any one notary fails (or, more precisely, conflicts with other notaries) your system should take note. And with enough other notaries in operation, as the system is meant to be used, you continue without problem. (Indeed, notaries could be monitored (by your system, as you use them) and notary judgement could be weighted by longevity of good service.) If a notary fails, it's not a problem, it's an anticipated design constraint.
Compromised notaries are accounted for as a fundamental part of the technique. So it is clearly not the same problem as compromised CAs.
You don't understand firewalls. Firewalls act on IP addresses and ports. They do their work before a SSL negotiation can begin, making SSL entirely irrelevant.
I understand firewalls. Pardon me if I haven't been clear.
The point is that you can't block notaries by IP because virtually any machine on the net can be running a notary (which is why I mention DNS and other such services, for their virtue of being easy to run by sysadmins the world over). Nor can you block them by port because they use 443. Nor can you block them by deep packet inspection, because they use TLS/SSL. Thus SSL is relevant.
Sure, but now checking your mail involves finding and using a proxy, or caching certs in advance. Convenience is an important part of security. Nobody will bother with it if it requires arcane incantations every time.
You said manual CA list editing was an acceptable solution in a worst case scenario. Yet reconfiguring a notary list is off limits? You'll have to distinguish the two so this doesn't look like self-contradiction.
And note that cert caching is a part of the design. Invisible to the user, not an "arcane incantation". This information was in the video. When you say things like this it makes me think you're trolling.
Would the EFF run a notary? Perhaps they'd even run a network of notaries? Would any of a number of freedom-promoting organizations run notaries? Why not individual system administrators?
How do you know it's the EFF notary? Again, you need to bootstrap your system. How does that work?
I'll take that as your concession that trusted organizations could indeed be reasonably expected to run notaries.
Yes, the bootstrap is the part I'm mulling over. What ideas do you have for it?
I could certainly add your notary to my list.... If your notary started returning bogus values (not agreeing with the other notaries), it would reveal itself as corrupt.
I'm not sure this works long term. It seems too maintenance intensive. If you leave that to the end users, it will end up going very wrong sooner or later, I think.
Notary list management could even be done automatically. Come on, put your imagination towards making it work, not just tow
The worst thing they can do is to use their CA to emit a valid cert for gmail.com and spy on me that way. That is a big problem, but I can remove the chinese CA from my system. Certainly this isn't perfect at all, but workable to some extent.
Remove the Chinese CA? That idea is "trust agility". You're suggesting you have some ability to change who you trust with modifying browser CA lists. It's quite minimal, really:
Did you remove the Diginotar cert? Or did you wait for your browser or OS to get an update? Eventually we discovered there were more than one cert:
DigiNotar Root CA
DigiNotar Root CA G2
DigiNotar PKIoverheid CA Overheid
DigiNotar PKIoverheid CA Organisatie - G2
DigiNotar PKIoverheid CA Overheid en Bedrijven
DigiNotar Root CA Issued by Entrust (2 certificates)*
DigiNotar Services 1024 CA Issued by Entrust*
Diginotar Cyber CA Issued by GTE CyberTrust (3 certificates)*
Handling that is not very workable.
And what if the CA is someone like Verisign? Do you remove Verisign? And make a quarter of HTTPS connections show up as invalid? Too big to fail is another failure of trust agility.
And did you know that Diginotar's website had been hacked as far back as 2 years ago? And they never noticed or fixed it until now. Could their CA cert have been compromised then? 2 years of exposure, without a hint so we couldn't have removed the certs even if we knew which ones were relevant.
And there are over 500 organizations your browser trusted in addition to Diginotar. What are the chances that any one of them is being run badly? Or, the better question, how many other Diginotar-alikes are sitting in your browser at this very moment? The logical OR of the current browser CA system is a failure.
And, anyway, this scenario assumes you can block the notaries. Anyone can run a notary. Not everyone has to publicize their notary.
And if they firewall it off country-wide I have no way to reach it at all.
I assume "it" refers to notary access. I pointed out earlier that firewalling by protocol or port would be problematic because Convergence notaries use HTTPS.
And if they managed somehow to block all notaries by identifying some quality of the requests, you might still be able to access them via web proxy or SSH.
And if they managed somehow to block all notaries by identifying some quality of the requests, and they could block all web proxy and SSH connections, you would still likely have a cache of important sites' certs.
And if they managed somehow to block all notaries by identifying some quality of the requests, and they could block all web proxy and SSH connections, and you didn't have a cache of important certs, the Convergence protocol is extensible such that a local notary could return its "OK" or "NOK" based on results from any method it chooses, not only "whether seen". Notaries could use DNSSEC, or "whether seen" via Tor, or a PGP Web of Trust, or even the existing CA system. You could have such a notary running locally as a fallback.
Where the CA system requires only one -- just one CA -- out of half a thousand organizations to vouch for a cert -- and you have no choice about it using that method -- notaries-based systems can be configured to require some number/percentage of notaries to agree, out of a quorum. Who you trust and how you trust them is your decision. And you can change your mind.
First, if the notaries aren't published anywhere, how do people find about them? Very very few people are going to run their own notary. Few people understand all this stuff, and even fewer have the means to run a notary that has a different perspective than their own.
Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.
You're on such a compromised net and you visit an HTTPS site...
If you have the cert cached, you won't need a notary check. Authenticated communication proceeds.
You're seeing the cert for the first time, but Convergence can't talk to notaries. So the cert shows up as not validated. You can cope with that. Don't trust the site. Switch to the next available wireless network and try again. Maybe you'll have to leave the cafe and walk down the street. Or even go home. Anyway, distrusting the site can be done. Changing the network can be done. Blocking notaries is not any sort of significantly compromising MiTM.
And, anyway, this scenario assumes you can block the notaries. Anyone can run a notary. Not everyone has to publicize their notary.
The notary list is public.
There is a public notary list. But it is not the only list and it's not comprehensive. Anyone can run a notary. The larger and more diverse the ecosystem of notaries is, the healthier the scheme. How many people run their own DNS or NTP servers? How will you block all possible notaries?
What if the client itself is running multiple notaries that use proxies on the wider net to get certs?
I strongly suspect the nature of notaries is not being understood.
It will happily mark as valid a certificate for gma1l.com, with the metadata copied from the gmail certificate.
It will do no such thing!
That's pretty far from how notaries work.
I must say I find it very frustrating to see you going on with apparent certainty regarding something you evidently don't understand. And it should be obvious to you that you don't understand it. And you appear resistant to clicking a link and watching a video that would clarify it for you. You, sir, owe me an apology.
Granted, the video is a little long. But I implore you to weigh that against the time you'll spend misinforming people and creating pointless argument, among other problems.
It depends on the availability of a third party. SSL works fine with just the server you connect to, but for this you need to talk to the same set of servers for any certificate check. That makes it easy to block. Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.
CA SSL requires "third party" net access for certificate revocation checks (OCSP).
That CA SSL cert revocation using third parties is (as it's handled in most situations) susceptible to replay attack.
Blocking a potential victim's access to n out of m notaries (where n equals something of the user's choice and m equals a potentially huge number of systems) is an unlikely attack.
The user may decide to change their current list of notaries to circumvent a block. ("trust agility")
Convergence notaries appear to use HTTPS, so blocking becomes yet more challenging.
Convergence caches good certs, so the block has to occur at the right time.
It doesn't do many of the duties of a CA. It will happily mark as valid a certificate for gma1l.com, with the metadata copied from the gmail certificate.
It's not the metadata that's the threat during a phishing attack. The threat comes from being a CA-signed cert, which, regardless of the name in the cert, your browser tells you is "secure".
Or maybe you're saying that CAs protect against people registering look-alike domains? I doubt that.
And (simple) notaries don't mark certs as valid, they report them as seen. Then you (via configuration of your software) decide on what is valid.
I would believe a handful of trusted notaries who all say they've seen gmail.com using certificate abc123 for a whole week. More so than I would trust when just one of several hundred race-to-the-bottom CAs in my browser says that certificate xyz789 is gmail.com.
It's still a CA, except one that follows a different policy. It's just as breakable. What guarantee do you have that their servers return accurate information?
I think maybe you're not clear on the concept of notaries or "multiple perspectives". Or "trust agility".
Slashdot Mirror
Doesn't look Markov to me.
It looks like a longstanding Slashdot user who may be (going) schizophrenic.
The tendency for infection is correlated to how popular the OS is, goes the oft-repeated idea.
For relative infectibility, I quote the "exposed to malware" numbers from the article. They make it a little ambiguous whether this means actual infections. And for relative popularity between Windows OSs, I quote from the Wikipedia article on Windows (with some averaging).
"Exposed To Malware"- XP - 41%
- Vista - 38%
- 7 - 16%
(Relative) Install BaseAppears to be a large discrepancy between these numbers. Any explanations? On the face of it it looks like it is not true that popularity of OS correlates highly with infection rate.
What I'd like to see is a protocol for handling all the social interactions that Facebook provides. Then folks could write apps and servers to implement it. Technically-minded nerds could run their own servers. Other folks could just choose whichever provider they pleased, much like selecting mail or web hosting.
Decentralize.
My browser has Perspectives and Certificate Patrol. This way I know if other network locations are seeing the same cert that I'm seeing, and whether that cert's changed recently.
Technological advance is the purview of many, not only technophiles, academics, or governments. Technology to monitor and correlate just advances. Other than that, I agree with you.
More data goes online every day, even aside from what we put there ourselves, data sourced a myriad ways, ways multiplying constantly. It's a(n ever more) digital life.
There's no pulling the plug. There's only learning to cope. It's just fact that our lives, the lives of everyone, grow ever more transparent.
So, how will we adjust?
So long as we don't end up with a single browser dominating the market again.
The Great Languish of the web really sucked. Molasses advance of technology and compromised systems galore.
I was wondering whether there were some damage potential from capsaicin.
Etc.
Impossible to answer. What defines a serious project versus someone's pet project or proof of concept? Then of those, how do you measure success? How many Sourceforge projects "see the light" outside Sourceforge?
This is the question you seem to be getting an answer to in the forum here. Hopefully it helps.
"More Powerful than" and "better at" here mean "lend themselves conveniently to such tasks in the given context (of the command line)".
Yes, for file handling, launching commands, and for simple inter-process communication shells — all shells, not just bash — are far more convenient than Python or Perl.
ps without -f does not show the full command line — you won't see the args to awk.
Alternatives:
Don't fire off grep when you fire off ps (which you did by piping to grep) — do your grep after the ps completes.
O=`ps -ef`;echo "$O"|grep bluefish|awk '{print $2}'
O=`ps -ef`;echo "$O"|awk '{/bluefish/ print $2}'
If you're not actually looking for something on the command line, don't print whole command lines, just the commands. ps without flags.
ps|awk '/bluefish/ {print $1}'
Specify to ps the executable command you wish ps to show you.
ps -C bluefish|awk '/bluefish/ {print $1}
And output only its PID (and hide output headers).
ps -C bluefish -o "pid" --no-headers
Or use pgrep.
pgrep bluefish
psh (Perl shell) sounded like a good idea. Never looked into it, though. Wonder what happened to it.
That doesn't sound quite right. I did personally learn most of my basic command line skills in a windowing-free environment, but I don't think it's necessary.
I think that even after 20 years of command line experience I could learn new things. Regardless of running X.
See, this is a weird idea, too. That command line skills might come in handy. I use the command line every day. Maybe you use some kind of file management app like Windows Explorer? I file manage through the command line. Probably not the most efficient way (I never did learn tools like Midnight Commander), but the command line works well enough.
That's about all you need to start.
This bit of the article is intriguing:
What are the ways in which HTML/CSS+JavaScript is not an effective platform v. native apps? What can be done about it?
And note the general market is coming around, yo.
Diet-based gene expression regulation sounds like a fun way to semi-plausibly rationalize the idea of eating animals to gain their traits.
This "decentralized SSL Observatory" idea is fantastic. The notaries paradigm we've been discussing (Perspectives, Convergence) requires multiple views for efficacy, the more the better (within certain parameters). I'd been imagining a system in which individuals could opt to be notaries/cert reporters, and this is a step in that direction. Now the EFF could turn into a nexus for thousands and thousands of views. Of course they'd aggregate those thousands of views into a single point of failure, but that's okay, you'd only be using the EFF as one notary in your council of many. There are plenty of other trustworthy organizations who could run their own notaries based on similar methods or otherwise effective methods. I expect even individuals will run their own notaries, much as they run Tor servers or even NTP or SMTP.
If we're getting down to the level of manually removing CAs, there's a lot of security inconvenience that's "acceptable".
That would certainly be an improvement.
Notaries are different from CAs.
If any one CA tells you a site is good, your browser says it's good. So if any one CA fails, your security is broken. And in a bad way. A false positive way.
If any one notary fails (or, more precisely, conflicts with other notaries) your system should take note. And with enough other notaries in operation, as the system is meant to be used, you continue without problem. (Indeed, notaries could be monitored (by your system, as you use them) and notary judgement could be weighted by longevity of good service.) If a notary fails, it's not a problem, it's an anticipated design constraint.
Compromised notaries are accounted for as a fundamental part of the technique. So it is clearly not the same problem as compromised CAs.
I understand firewalls. Pardon me if I haven't been clear.
The point is that you can't block notaries by IP because virtually any machine on the net can be running a notary (which is why I mention DNS and other such services, for their virtue of being easy to run by sysadmins the world over). Nor can you block them by port because they use 443. Nor can you block them by deep packet inspection, because they use TLS/SSL. Thus SSL is relevant.
You said manual CA list editing was an acceptable solution in a worst case scenario. Yet reconfiguring a notary list is off limits? You'll have to distinguish the two so this doesn't look like self-contradiction.
And note that cert caching is a part of the design. Invisible to the user, not an "arcane incantation". This information was in the video. When you say things like this it makes me think you're trolling.
I'll take that as your concession that trusted organizations could indeed be reasonably expected to run notaries.
Yes, the bootstrap is the part I'm mulling over. What ideas do you have for it?
Notary list management could even be done automatically. Come on, put your imagination towards making it work, not just tow
Remove the Chinese CA? That idea is "trust agility". You're suggesting you have some ability to change who you trust with modifying browser CA lists. It's quite minimal, really:
Did you remove the Diginotar cert? Or did you wait for your browser or OS to get an update? Eventually we discovered there were more than one cert:
Handling that is not very workable.
And what if the CA is someone like Verisign? Do you remove Verisign? And make a quarter of HTTPS connections show up as invalid? Too big to fail is another failure of trust agility.
And did you know that Diginotar's website had been hacked as far back as 2 years ago? And they never noticed or fixed it until now. Could their CA cert have been compromised then? 2 years of exposure, without a hint so we couldn't have removed the certs even if we knew which ones were relevant.
And there are over 500 organizations your browser trusted in addition to Diginotar. What are the chances that any one of them is being run badly? Or, the better question, how many other Diginotar-alikes are sitting in your browser at this very moment? The logical OR of the current browser CA system is a failure.
I assume "it" refers to notary access. I pointed out earlier that firewalling by protocol or port would be problematic because Convergence notaries use HTTPS.
And if they managed somehow to block all notaries by identifying some quality of the requests, you might still be able to access them via web proxy or SSH.
And if they managed somehow to block all notaries by identifying some quality of the requests, and they could block all web proxy and SSH connections, you would still likely have a cache of important sites' certs.
And if they managed somehow to block all notaries by identifying some quality of the requests, and they could block all web proxy and SSH connections, and you didn't have a cache of important certs, the Convergence protocol is extensible such that a local notary could return its "OK" or "NOK" based on results from any method it chooses, not only "whether seen". Notaries could use DNSSEC, or "whether seen" via Tor, or a PGP Web of Trust, or even the existing CA system. You could have such a notary running locally as a fallback.
Where the CA system requires only one -- just one CA -- out of half a thousand organizations to vouch for a cert -- and you have no choice about it using that method -- notaries-based systems can be configured to require some number/percentage of notaries to agree, out of a quorum. Who you trust and how you trust them is your decision. And you can change your mind.
The system is in the process of be
What exactly is the threat model you're positing?
Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.
You're on such a compromised net and you visit an HTTPS site...
And, anyway, this scenario assumes you can block the notaries. Anyone can run a notary. Not everyone has to publicize their notary.
The notary list is public.
There is a public notary list. But it is not the only list and it's not comprehensive. Anyone can run a notary. The larger and more diverse the ecosystem of notaries is, the healthier the scheme. How many people run their own DNS or NTP servers? How will you block all possible notaries?
What if the client itself is running multiple notaries that use proxies on the wider net to get certs?
I strongly suspect the nature of notaries is not being understood.
It will happily mark as valid a certificate for gma1l.com, with the metadata copied from the gmail certificate.
It will do no such thing!
That's pretty far from how notaries work.
I must say I find it very frustrating to see you going on with apparent certainty regarding something you evidently don't understand. And it should be obvious to you that you don't understand it. And you appear resistant to clicking a link and watching a video that would clarify it for you. You, sir, owe me an apology.
Granted, the video is a little long. But I implore you to weigh that against the time you'll spend misinforming people and creating pointless argument, among other problems.
It depends on the availability of a third party. SSL works fine with just the server you connect to, but for this you need to talk to the same set of servers for any certificate check. That makes it easy to block. Somebody doing MITM will just block you off Convergence, then you won't know if the self-signed cert is any good.
It doesn't do many of the duties of a CA. It will happily mark as valid a certificate for gma1l.com, with the metadata copied from the gmail certificate.
It's not the metadata that's the threat during a phishing attack. The threat comes from being a CA-signed cert, which, regardless of the name in the cert, your browser tells you is "secure".
Or maybe you're saying that CAs protect against people registering look-alike domains? I doubt that.
And (simple) notaries don't mark certs as valid, they report them as seen. Then you (via configuration of your software) decide on what is valid.
I would believe a handful of trusted notaries who all say they've seen gmail.com using certificate abc123 for a whole week. More so than I would trust when just one of several hundred race-to-the-bottom CAs in my browser says that certificate xyz789 is gmail.com.
It's still a CA, except one that follows a different policy. It's just as breakable. What guarantee do you have that their servers return accurate information?
I think maybe you're not clear on the concept of notaries or "multiple perspectives". Or "trust agility".
Anyone unclear on the concept should check out this great video on how notary systems work.
I highly recommend reading Manna. It's a quick read, and a junior effort at writing, but the ideas are well worth contemplation.
That sounds more like marketing driven than market driven.
market driven: Determined by or responsive to market forces.