When rates go up, defaults go up on ALL of them. Systemic risk, which is exactly what bundling things together is supposed to mitigate.
...it's worse than that, because when rates go up and defaults go up, the value of property - which is hugely influenced by the price and availability of mortgages - goes down. Oh, and if banks rely on the profit from selling CDOs to enable then to offer cheap mortgages, any glitch with CDOs will put up the price of mortgages which...
...and it gets worse still! Suddenly, instead of offering long-term mortgages at competitive rates, banks were offering "bargain" discount or fixed-rate deals for 2 years, after which customers were forced to either re-mortgage or have their payments revert to an exorbitant "standard" rate. Nothing to do with banks making more money trading CDOs and suchlike every time someone re-mortgaged than they would by retaining long-term customers, I'm sure. Of course, this makes the property market even more volatile because anybody who, for whatever reason, is unable to re-mortgage is up shit creek when their bargain deal runs out.
Ergo, CDO's are a pretty dumb idea prone to catastrophic, self-accelerating failure with all sorts of unintended consequences. If you wanted security, you'd bundle mortgages with gold, oil, cheap vodka futures or something else that tend to go up when the credit market tanks. Even if they don't require outright fraud they make it easier, and tempting.
The old idea that people working in some specific profession produce nothing of value to society.
I take it you've just come back from Mars: currently, "producing nothing of value to society" would be such a massive improvement for the finance sector that even I wouldn't begrudge them a bonus...
The inventor of the mobile phone fart app has more to be proud of than the inventor of the CDO.
Of course, some people in finance might still be doing useful work - e.g. taking deposits from people with surplus cash and lending it, at a slightly higher rate, to people with short-term cashflow problems. Maybe such people should find a new name for what they do, because that sort of thing ceased to be the main business of the banks when they found that they could play insane money games with our cash, keep the winnings and send us the bill if they lost.
Can someone name me some actual real world, large software projects based on functional programming?
That's not the point - functional programming is more relevant to the theory of computing, formal analysis of algorithms, Turing, Lambda calculus and all that jazz. If I did a Computer Science degree, that's what I'd expect to be taught (and have to expend brain cells to understand) - you can pick up Java or Objective C from a book.
Web servers already display different content to users based on their geographical location or their login cookies or any number of state variables, and these content changes are not reflected in the URL. Your point means nothing.
Nonsense. Geographic location, login cookies etc. are not part of the URL. The protocol string is part of the URL. You can't hide it. If a webmaster decides to make their URL ambiguous, that's their decision - but a browser shouldn't make URLs ambiguous by design.
This is a tautology. Since today's browsers are so alarmist about self-signed certificates, the use of self-signed certificates is automatically fishy.
Taking account of the status quo is not a tautology. We have a world where most of the web uses unencrypted http (and is quite happy with it) and https is only used where a "secure" connection is required. Maybe the way browsers treat https is part of the reason for that, but that's far from the only explanation - encryption has a processing overhead and buggers up proxying/cacheing, and the vast majority of websites were passive online hypertext. Nowadays, processors are faster and more and more websites are "dynamic" in some way (which also makes proxying/cacheing less relevant). If you were designing the web today, from scratch, then it might well make sense to use encryption in the default protocol and make the "secure" option entirely about trust - but sadly you're lumbered with the legacy of the 1990s web.
The same holds for regular http. Someone could be mounting a man-in-the-middle attack with regular http.
That's an almost meaningless statement: anybody can simply eavesdrop on regular http. It doesn't promise any security at all. Self-signed https: promises security, and end users aren't qualified to judge when that security is appropriate. I predict that, if you asked random users, quite a few would tell you that "https" meant "secure" but very few would understand the risks of a self-signed certificate.
With regular http (and only regular http), large-scale attacks like police surveillance and content filtering become possible.
...if you are worried about privacy, why on earth would you blindly trust the identity of the sites you visit? Content filtering is easier to achieve by blocking sites or threatening to hit service providers in the wallet, and if https ends up crimping Big Brother's style too much, he'll simply force ISPs to block it. If BB wants to waste time and money indiscriminately trawling through traffic instead of more sophisticated, targetted attacks then that's his (and the taxpayers) funeral.
Again, the fact that self-signed certificates are out-of-the-ordinary is a tautology that you helped to set up by insisting that they be treated as out-of-the-ordinary.
Actually, you're the one relying on a tautology, I have the real world on my side. You are saying that if many more sites used self-signed https: then it wouldn't be unusual for a typical user to encounter it. You are also completely relying on your assertion that the handling of self-signed https in some browsers is the predominant reason for its scarcity. I'm just taking account of what happens in the real world. Do you seriously think that the typical browser user is encountering self-signed certificates on a regular basis, or that they don't predominantly use https for dealing with banks and e-commerce sites which would be expected to have a trusted certificate? The self-signed certs I encounter are mainly my own, and when I do encounter one elsewhere then, yes please, I'd like my browser to scream at me (and to warn off my less technical colleagues).
NO! That's not what firefox does. If firefox did in fact do what you claimed it did, then I would be happy.
There's no reason why browsers have to display "https://" or even "http://".
Except, that's a significant part of the address. "http://somesite.org" and "https://somesite.org" could, potentially, point to different content (certainly different vhosts). Yeah - its a mess (often leading to redundant use of the protocol string, port number and "www" subdomains), but browser designers aren't in a position to fix that from their end.
Nobody here is arguing that self-signed https connections deserve a "golden padlock."
No, but browsers do need to advise non-technical users, who don't understand the technical distinctions, in the simplest justifiable terms whether a connection is "secure" or "insecure".
The proposal is that we should treat self-signed https connections the same as unencrypted http connections.
Sites using https generally do so because they want to exchange sensitive data, and the use of a self-signed certificate might indicate that a MiM attack is in progress, or (possibly more likely) that the site is being run by a cowboy outfit who can't be arsed to get proper certificates. So, a self-signed https connection is always slightly fishy (there are plenty of innocent explanations, but identifying those requires human judgement + technical understanding).
I have yet to see anybody articulate an even remotely coherent argument against this proposal.
http = no expectation of security, and responsible web designers wouldn't use it to exchange sensitive data. In theory, people should be warned whenever they submit data over http. Indeed, some browsers do (did?) do this but it was incredibly annoying so everybody turned it off.
https = strong expectation of security. Web-sites usually use this because they have something to protect and, usually, get a proper certificate. Its pretty pointless using https for a passive website - and tinfoil hats who want to cover their tracks will want something more sophisticated anyway.
self-signed https = someone could be mounting a man-in-the-middle attack or you may have been spoofed/phished to the wrong website. Unlikely (especially c.f. the risk of evesdropping on http) if you're connecting to your home server, but not to be lightly ignored if you are logging in to your bank account (at best, it means your bank's IT department is incompetent and you shouldn't touch their e-banking service with a bargepole). This is not the same as http.
So, where is the best place, for a browser to start ringing alarm bells? Technically, (1), because you shouldn't be sending sensitive information over http, and the browser can't reliably tell what constitutes "sensitive" . In practice, however, this is incredibly obtrusive (there's plenty of non-sensitive items you can enter in a browser) and risks "training" users to ignore warnings.
I'd suggest (3) is by far the best place at which to start nagging - most users will rarely encounter this situation (only sites with very small user bases, like home servers or in-development sites have a real excuse for not getting a cert) so you're not going to swamp typical users with bogus warnings. For the typical user, this does mean that something out-of-the-ordinary is happening.
And remember at the end of the day, all browsers like firefox actually do is warn you, encourage you to view the certificate and decide whether you want to trust it temporarily or permanently - using language that will deter anybody who doesn't understand what is going on. That's pretty good practice for anybody encountering a self-signed cert. Its annoying if you're a web designer testing sites using self-signed certificates, but you are not the target audience.
So this issue is not a technical but a social one.
Unless you see technology as a self-justifying end in itself, rather than as a tool to solve real-world problems (which often have social dimensions) that's not a useful distinction. Technology is pointless unless it accounts for the social dimensions.
Technically, self-signed HTTPS is more secure than plain HTTP, but only by a small margin.
In certain circumstances (e.g. a major bank or e-commerce site which could be a juicy enough target to attract sophisticated attacks) HTTPS with a self-signed certificate is actively suspicious and warrants a warning. Your browser can't distinguish these from circumstances in which encryption alone is adequate.
HTTP is just plain insecure, and there shouldn't be any expectation of security. Also bear in mind that some (most?) browsers do, by default, warn you if you submit a form over a plain HTTP connection (although everybody then clicks "don't show this message again" - a true nanny society wouldn't give you that option, but you have to draw the line somewhere).
...and on a practical level, most current HTTPS sites (a) do have a trusted certificate and (b) use HTTPS specifically because they are going to collect some sensitive information, so "HTTPS without trust" is a fairly sensible threshold to start warning people without drowning them in warnings.
So, why not visually display both self-signed HTTPS and HTTP the same, instead of marking one in bright red?
Because some people will think "https means secure, right?" and need to be actively warned when it is not.
Then change the padlock with an open door for HTTP, a close door for self-signed HTTPS and a packlocked door for certified HTTPS?
That violates "keep it simple, stupid". You're still designing for someone like you, who knows and cares about the distinctions, rather than a random user.
The best message for random users is still "don't use self-signed https sites unless you understand the risk".
Wow, the end-user are warned as if it is more dangerous than plain HTTP site!
Yes, a self-signed https connection can be more dangerous than a plain http one if you see the "https" or the "golden padlock" and assume you have a secure connection.
You're confusing a specific tool (encryption) with the job (a browser establishing that a connection is sufficiently secure to justify displaying the "golden padlock" that non-technical users are told to look for before they enter their credit card details).
To do the job properly the browser needs encryption and some way of confirming the identity of the remote site. In the general case, encryption alone is not secure.
You may have a specific application in which you judge encryption alone to be sufficient (e.g. setting up a login for your blog so you can remember user preferences) but for other applications it is inadequate (you wouldn't log in to an e-banking site if it used a self-signed certificate, would you?) Plus, if you are a webmaster, even if you are capable of making that distinction yourself, you don't have the right to decide, on behalf of all your users, that they should trust you.
Now, the certificate-signing system is a million miles from perfect (as TFA shows) and its probably the weakest link in https, but identity verification and "trust chains" are always going to be much messier than pure encryption, and its the best we have and/or that people are prepared to put up with. "Encryption + certificate signed by a trusted authority" is the "least worst" criteria we currently have for telling a non-technical user that their connection is "secure".
A more rational mechanism should be telling users the truth honestly, i.e. "this site's traffic is encrypted and the authority is promised by xxx.com, or if self-signed, self-proclaimed"
Let's translate that message into how a typical browser user would understand it:
"This site's tetrion beam is modulated by an inverse tachyon pulse created by reversing the polarity of the neutron flow in the Heisenberg compensator. Abort/Retry/Ignore?"
...and from that, is supposed to decide whether they can safely type in their credit card number? Of course not - the best you can hope for is to educate them to "look for the secure connection icon". In that case, the only responsible advice that a browser can give about an unsigned certificate is "don't trust this site unless you understand the risks".
Because Apple prevents competition with legal threats.
...and if they hadn't, they'd be getting legal threats from the recording industry, who (at the time) only allowed Apple to sell their music on the promise of secure DRM. Providing alternate ways to sync music to the iPod circumvents this. That's changed for music - but the issue has now moved on to video and software.
The monopoly/cartel here is not Apple, but the recording industry, who were trying to force DRM on the public. The trouble is with DRM - unlike encryption - is that its very hard to implement in an "open" way, because if the user has access to the code, they can extract an unencrypted version. Actually, DRM is pretty futile full stop.
Please remember when all that was happening Apple was alive and well selling desktop computers, and Linux had a huge share of the server (particularly web server) market and a sliver of the desktop market.
In the late 90s, if you walked into a typical computer store, or picked a random online/mail-order reseller you'd usually find all of the desktop computers came with Windows, and all the software was for Windows (in larger stores there may have been an out-of-date Mac and a boxed copy of Office for Mac). If you asked the assistant about installing Linux you'd probably get some bullshit about voiding the warranty, or, more likely, a blank stare (if you were really lucky, an out-of-date copy of Red Hat on the software shelf). If you picked up a magazine with "Personal Computer" in the title you'd find 2 column inches on Mac, 2 column inches on Linux and the rest of the magazine about Windows PCs. If a software ad didn't mention what operating system it ran on, they meant Windows. Most of the cheaper peripherals only worked with Windows. Then there were all the websites which only worked properly on Internet Explorer.
The digital audio player market has never been like that - apart, maybe, for a short time after the iPod's launch I've always seen a reasonable range of non-iPod "MP3" players on offer, even more so if you count things like car stereos and CD/DVD players with "MP3" playback. Even 3rd-party speakers with iPod docks tend to have audio inputs for other devices. Any nascent iPod monopoly was ended once and for all when phones started to offer digital music (I suspect this was the real reason Apple made the iPhone). Apple's iPod/iPhone/iTunes may be market leaders, but it only looks like a monopoly when you start narrowing the definition to e.g. "touch screen portable audio devices over $200".
Its hardly surprising that Apple have a brief "monopoly" when they invent (or, more accurately, successfully market) a new sub-genre of device or service. Android is now doing well against iPhone, and its only really in the last year that Android devices started to bear comparison with the iPhone (I have an 18-month old Android phone and, believe me, it doesn't compare). It looks like its going to be another year before Android tablet makers "get it" and start competing with iPad - and then that will stop looking like a monopoly.
Ripping from a CD is not illegal in any way shape or form if you own the CD and rip it for your own use.
It is in some countries, e.g. here in the UK, although everybody realises it is stupid, I don't think anybody has ever been prosecuted and there is talk of fixing the law.
However, everybody ignores the law so, yes, buying a CD and ripping it is, and always was, a perfectly viable "competitor" to iTunes.
With unencrypted data mallory can merly evesdrop. Evesdropping is easy and safe.
That's a bogus comparison - the insecurity of plain http is irrelevant. If the user has gone to a "https" site and/or if they see the "secure" indicator on their browser then they are expecting a secure connection.
A https connection without identity verification is less secure than a https connection with self-signed certificates - the browser has to "explain" this to non-technical users.
You're looking at this from the perspective of a power user who understands what is going on. Browsers are written for non-techies who, at best, have been told "look for the golden padlock". Since the browser can't tell a bank from a blog, the only responsible thing it can do is tell the user that the connection is untrusted.
All good points, except perhaps that the expense of certificates is not an issue for any business, even small ones
You've obviously never worked in a large, penny-wise-dollar-foolish, organization, where, if a $50 certificate hasn't been costed into a project and/or if your pointy-haired boss doesn't think its necessary and/or if you have to contact the legal department to produce the necessary confirmation of authority documents and/or the provider wants a credit card number and isn't on the approved suppliers database, then it might as well cost $50,000,000,000*. That can be particularly awkward if you want your site to keep working after the end of a project.
(* Slight exaggeration to account for the emotional distress of dealing with the bureaucracy).
THe problem is that the browsers persist under the myth that certs can ONLY be used for proving the identity of a host; and completely disregard the fact that an equally valid and completely unrelated task is traffic encryption.
The trouble is, identity checking and encryption are inseparable.
Public key encryption doesn't allow Bob to securely exchange data with Alice: it allows Bob to securely exchange data with someone claiming to be Alice who has given Bob what she claims to be Alice's Public Key.
Without some way for Bob to verify that the person claiming to be "Alice" is, indeed, the real Alice that's about as much use as an ashtray on a motorbike.
Where self-signed certificates are useful is when you've independently verified that the site you are connecting to is genuine (translation: you have crossed your fingers and decided that your piss-ant little site is not interesting to the black hats) - but the browser can't know that you've done that. The only responsible thing the browser can do is warn you that (as far as it is concerned) the connection could still be insecure before displaying the "secure connection" symbol.
If you're using self-signed certificates then you need to be in close enough touch with your users to reassure them about the browser warnings. If you have too many users for that to be practical then you shouldn't be using self-signed certificates. Otherwise, you're acting like my bank, who cold call me and then wonder why I won't answer their security questions - they know they're genuine, but they can't get it into their heads that the customer doesn't know, and shouldn't assume, that.
A more standards compliant IE is always to be welcomed. What should not be welcomed is that "more" standards compliant != standards compliant.
For the sake of balance, the best that Firefox, Safari/Webkit, Opera et. al. can claim is that they are "more" standards compliant than past Microsoft efforts. There are plenty of glitches when trying to use (say) scripted SVG or more recent CSS features on multiple non-MS platforms (not to mention the current total existence failure of SVG on Android). Also, forget 3D, does any browser properly support the CSS printing control attributes (most support "page-break: before" but that's it).
Part of the problem is W3C's tendency to produce late, hard-to-implement standards with no reference implementations (including some complete turkeys like CSS).
Things like web workers & WebGL are not implemented in IE9 which is quite disturbing.
A quick check suggests that WebGL is only currently available in Chrome (ignoring development versions of other browsers, where it may or may not be enabled in the next release). Web workers don't seem to be available in Android/iOS (and sounds like just the sort of thing that Apple will take exception to!)
However, assuming that the other browsers will get their act together soon, this time round, the joke could be on Microsoft. This time, the tablet/phone market is huge - particularly for the sort of casual games WebGL could be used for - and MS barely have a toe-hold in it. If MS makes developers choose between supporting IE and supporting iOS/Android then (given other browsers are available for Windows) they might not like the result.
no wonder samsung is finding it difficult to compete with its 1gb ram tablet with a 2mp front cam and an 8mp rear cam, 1080p recording, dual core graphics, dual core cpu.
So why don't Samsung produce a camera with less RAM (the iPad 1 seems to work fine with 256MB) a VGA front cam (more than good enough for video calling) and a 720p rear cam (why the fsck would you want to record 1080p through a pinhole lens on a device with limited internal storage or take 8MP photos on a slab which is ergonomically hopeless as a camera?) Making sure it has the latest version of Android (i.e. one actually designed for tablets) would be a good idea, as would not choosing a lame 7" form factor (16:9 to boot) that makes it too big for a phone and too small for a tablet.
If devices like the XOOM and Galaxy Tab were undercutting Apple and had these higher specs then yes, that ought to be a winner (more RAM/better Cameras is certainly nice to have) but they're not. Nor are they going to get anywhere until Android Honeycomb is out and stable.
However, I do wonder if Samsung/MOTO's problem is that they are pricing their tablet offerings according to the mobile phone business model: inflate the RRP so that carriers can offer big discounts with contracts.
...and copy the sleek design to create a product that is equally appealing to the eyes and twice or three times as powerful?
Ignoring the "economy of scale" issue (Apple orders displays, Flash etc. in huge quantities to get low prices) how do you make it twice or three times as powerful and still use the same parts?
Faster processors/graphics cost more. They generate more heat (so you can't pack them in as tightly) and they use more power (so you have to make the battery bigger or sacrifice battery life).
Higher-res cameras cost more, and probably use more power/generate more heat to boot. They're usually less sensitive (less light falls on each pixel) which means poorer low-light performance, or more amplification (more noise, more power, more heat => even more noise) or built-in illumination (more power/heat). Higher-quality cameras need higher-quality lenses which occupy more space.
Many of the "improvements" that Apple critics ask for also occupy more space or consume more power: more USB/SD/video connections = more space occupied by connectors and their internal cables and daughterboards + more complex and expensive assembly. Removable battery = user-proof internal battery connectors, extra protection to stop users damaging innards when replacing battery (more space, weight), need to make the battery rigid and safe to handle outside the case (more space, weight, less volume for battery) user-removable back (more space, weight...).
Sorry to burst your applesauce bubble, but 512mb ram is hardly ample in 2011.
Thanks for the valuable info. Without your wisdom, how would I know that the 256MB RAM on my iPad 1 was so pitifully inadequate?
On other systems, users would know that they had inadequate RAM due to the usual symptoms (machine slowing to a crawl, errors, crashes) but Evil Apple has conspired to ensure that these rarely happen on the typical iPad, fooling customers into think that, because their device runs perfectly, they have adequate RAM.
How would you like to run photoshop in a browser? That's a good test for how close the browser is to replacing the desktop. For myself, I also try to think of what it would be like to get a programming environment going from a browser. Right now, it's not a pleasant thought.
The point is not the browser - we're getting to the point where you can implement almost anything in JavaScript/DOM with, maybe, some server-side scripting thrown in. Even without the browser, large software suites are getting monolithic. Photoshop is part of a huge "creative suite" with its own workflow tools and plug-in ecosystem, a graphic artist need never go near the desktop (and if a lightbox application serves your needs better than a regular filing system, why should they?) . Eclipse is another example where you could potentially handle all the workflow for a complex development job within Eclipse (again, why browse your work by file when its better organised by class/object?) - heck, you could say the same for EMACS - and either of those could be implemented within a browser. The last time I played with this - a cloud/browser-based IDE it looked promising (and rather sensible for collaborative projects).
I think you've hit the nail on the head, there, although I'm not sure that its all about the browser. In fact, I think the desktop only ever truly lived on Mac and a few minority systems (Acorn RISC-OS is a good example in which the desktop became really central).
In the early days, a major (unsung) influence of the desktops on Mac and other systems was that it standardised the user interface. Before then, everytbody (Wordstar, Word Perfect, Lotus etc.) invented their own UI paradigm and even tried to prevent others copying it via look-and-feel lawsuits. With the early desktops, however, there was suddenly a single way to open, save, copy files, select blocks, copy, paste etc. and a fairly consistent menu layout across all applications (at least, per-platform - Apple were litigious towards competing desktops).
That didn't last long: pretty soon all the major software houses were trying to distinguish themselves with thier own systems of floating, dockable palettes, wizzards and unique icon designs, and started suing each other over look and feel again. In my experience, typical Windows users never really embraced the desktop (thanks partly to Windows' MDI mode) and just maximised their current application - often the only file manipulation technique they know is "Save as...". Unix/Linux suffered from the usual "Standard? Yeah we have lots of standards!" phenomenon, plus your typical *nix hacker regards a desktop as a mechanism for running 6 instances of vi and 3 xterms on the same screen.
Add to that, the tendency towards monolithic suites of programs with their own workflow management and, often, plug-in/add-on environments (MS Office and Adobe Creative Suite being the prime examples) many users who use their computer for specific jobs don't really need the desktop.
The browser/webapp is one influence - with no standard UI paradigm (or a choice of 3-4 if you used Java) everybody rolled their own. Now "Apps" and iOS/Android have brought the idea of the monolithic app, often with its own UI paradigm (although Android/iOS do provide standard widgets) well and truly to the fore.
Its a pity, really - without the Desktop/GUI as a standarsing mechanism, and application writers more worried about making their product visually distinctive than easy-to-use (and often confusing those things) computers can only get harder to use.
HB220 would require schools to teach students that the U.S. is a compound constitutional republic and about other forms of government such as pure democracy, monarchy and oligarchy along with political philosophies and economic systems such as socialism, individualism and free-market capitalism.
Is it just me, or does that sound a just a little bit more defensible than the spin in the summary?
I'm pretty sure a powerpc would spank an ARM on every benchmark
If you're talking about a G5 vs. your cellphone, of course - but an early-1990s desktop ARM chip vs. a early-1990s PPC would be a more interesting contest. Remember, ARM started out as a desktop chip - the first Acorn ARM systems in the late 80s smoked the competition (but, no DOS, no deal). Later they made the smart decision to focus on the mobile/low power market and leave the desktop to Intel space-heaters.
It would partly have been up to Apple to take the ARM core and team up with a chipmaker to specify a chip with the performance they needed, throwing in cache, FPUs and SIMD units to taste.
Remember the rumors when the Apple II flirted with using ARM cpus toward the end of the line when Jobs was herding the company heavily toward Motorola and the 68K?
Eh? The ARM might have been a contender for the last, education-only, gasps of the Apple II line, but Apple had committed to the 68K (with Lisa and then the Mac) back in the early 80s when the ARM was still a twinkle in Wilson & Furbers eyes.
It might have been a viable alternative to the PPC, though - that would have been interesting, but I fear it would have eventually hit the same problem: the chipmakers not keeping up with the brute-force Intel megahertz wars on the desktop because their main interests lay elsewhere (one of the factors that worked against Acorn's ARM workstations and eventually forced Apple to dump the PPC).
Slashdot Mirror
When rates go up, defaults go up on ALL of them. Systemic risk, which is exactly what bundling things together is supposed to mitigate.
...it's worse than that, because when rates go up and defaults go up, the value of property - which is hugely influenced by the price and availability of mortgages - goes down. Oh, and if banks rely on the profit from selling CDOs to enable then to offer cheap mortgages, any glitch with CDOs will put up the price of mortgages which...
...and it gets worse still! Suddenly, instead of offering long-term mortgages at competitive rates, banks were offering "bargain" discount or fixed-rate deals for 2 years, after which customers were forced to either re-mortgage or have their payments revert to an exorbitant "standard" rate. Nothing to do with banks making more money trading CDOs and suchlike every time someone re-mortgaged than they would by retaining long-term customers, I'm sure. Of course, this makes the property market even more volatile because anybody who, for whatever reason, is unable to re-mortgage is up shit creek when their bargain deal runs out.
Ergo, CDO's are a pretty dumb idea prone to catastrophic, self-accelerating failure with all sorts of unintended consequences. If you wanted security, you'd bundle mortgages with gold, oil, cheap vodka futures or something else that tend to go up when the credit market tanks. Even if they don't require outright fraud they make it easier, and tempting.
The old idea that people working in some specific profession produce nothing of value to society.
I take it you've just come back from Mars: currently, "producing nothing of value to society" would be such a massive improvement for the finance sector that even I wouldn't begrudge them a bonus...
The inventor of the mobile phone fart app has more to be proud of than the inventor of the CDO.
Of course, some people in finance might still be doing useful work - e.g. taking deposits from people with surplus cash and lending it, at a slightly higher rate, to people with short-term cashflow problems. Maybe such people should find a new name for what they do, because that sort of thing ceased to be the main business of the banks when they found that they could play insane money games with our cash, keep the winnings and send us the bill if they lost.
My whole point is that the status quo is so irretrievably broken that we must fix it
Good luck with that - grab your lance and chase those pesky windmills off your lawn.
Can someone name me some actual real world, large software projects based on functional programming?
That's not the point - functional programming is more relevant to the theory of computing, formal analysis of algorithms, Turing, Lambda calculus and all that jazz. If I did a Computer Science degree, that's what I'd expect to be taught (and have to expend brain cells to understand) - you can pick up Java or Objective C from a book.
Web servers already display different content to users based on their geographical location or their login cookies or any number of state variables, and these content changes are not reflected in the URL. Your point means nothing.
Nonsense. Geographic location, login cookies etc. are not part of the URL. The protocol string is part of the URL. You can't hide it. If a webmaster decides to make their URL ambiguous, that's their decision - but a browser shouldn't make URLs ambiguous by design.
This is a tautology. Since today's browsers are so alarmist about self-signed certificates, the use of self-signed certificates is automatically fishy.
Taking account of the status quo is not a tautology. We have a world where most of the web uses unencrypted http (and is quite happy with it) and https is only used where a "secure" connection is required. Maybe the way browsers treat https is part of the reason for that, but that's far from the only explanation - encryption has a processing overhead and buggers up proxying/cacheing, and the vast majority of websites were passive online hypertext. Nowadays, processors are faster and more and more websites are "dynamic" in some way (which also makes proxying/cacheing less relevant). If you were designing the web today, from scratch, then it might well make sense to use encryption in the default protocol and make the "secure" option entirely about trust - but sadly you're lumbered with the legacy of the 1990s web.
The same holds for regular http. Someone could be mounting a man-in-the-middle attack with regular http.
That's an almost meaningless statement: anybody can simply eavesdrop on regular http. It doesn't promise any security at all. Self-signed https: promises security, and end users aren't qualified to judge when that security is appropriate. I predict that, if you asked random users, quite a few would tell you that "https" meant "secure" but very few would understand the risks of a self-signed certificate.
With regular http (and only regular http), large-scale attacks like police surveillance and content filtering become possible.
...if you are worried about privacy, why on earth would you blindly trust the identity of the sites you visit? Content filtering is easier to achieve by blocking sites or threatening to hit service providers in the wallet, and if https ends up crimping Big Brother's style too much, he'll simply force ISPs to block it. If BB wants to waste time and money indiscriminately trawling through traffic instead of more sophisticated, targetted attacks then that's his (and the taxpayers) funeral.
Again, the fact that self-signed certificates are out-of-the-ordinary is a tautology that you helped to set up by insisting that they be treated as out-of-the-ordinary.
Actually, you're the one relying on a tautology, I have the real world on my side. You are saying that if many more sites used self-signed https: then it wouldn't be unusual for a typical user to encounter it. You are also completely relying on your assertion that the handling of self-signed https in some browsers is the predominant reason for its scarcity. I'm just taking account of what happens in the real world. Do you seriously think that the typical browser user is encountering self-signed certificates on a regular basis, or that they don't predominantly use https for dealing with banks and e-commerce sites which would be expected to have a trusted certificate? The self-signed certs I encounter are mainly my own, and when I do encounter one elsewhere then, yes please, I'd like my browser to scream at me (and to warn off my less technical colleagues).
NO! That's not what firefox does. If firefox did in fact do what you claimed it did, then I would be happy.
Sorry, that is exactl
There's no reason why browsers have to display "https://" or even "http://".
Except, that's a significant part of the address. "http://somesite.org" and "https://somesite.org" could, potentially, point to different content (certainly different vhosts). Yeah - its a mess (often leading to redundant use of the protocol string, port number and "www" subdomains), but browser designers aren't in a position to fix that from their end.
Nobody here is arguing that self-signed https connections deserve a "golden padlock."
No, but browsers do need to advise non-technical users, who don't understand the technical distinctions, in the simplest justifiable terms whether a connection is "secure" or "insecure".
The proposal is that we should treat self-signed https connections the same as unencrypted http connections.
Sites using https generally do so because they want to exchange sensitive data, and the use of a self-signed certificate might indicate that a MiM attack is in progress, or (possibly more likely) that the site is being run by a cowboy outfit who can't be arsed to get proper certificates. So, a self-signed https connection is always slightly fishy (there are plenty of innocent explanations, but identifying those requires human judgement + technical understanding).
I have yet to see anybody articulate an even remotely coherent argument against this proposal.
So, where is the best place, for a browser to start ringing alarm bells? Technically, (1), because you shouldn't be sending sensitive information over http, and the browser can't reliably tell what constitutes "sensitive" . In practice, however, this is incredibly obtrusive (there's plenty of non-sensitive items you can enter in a browser) and risks "training" users to ignore warnings.
I'd suggest (3) is by far the best place at which to start nagging - most users will rarely encounter this situation (only sites with very small user bases, like home servers or in-development sites have a real excuse for not getting a cert) so you're not going to swamp typical users with bogus warnings. For the typical user, this does mean that something out-of-the-ordinary is happening.
And remember at the end of the day, all browsers like firefox actually do is warn you, encourage you to view the certificate and decide whether you want to trust it temporarily or permanently - using language that will deter anybody who doesn't understand what is going on. That's pretty good practice for anybody encountering a self-signed cert. Its annoying if you're a web designer testing sites using self-signed certificates, but you are not the target audience.
So this issue is not a technical but a social one.
Unless you see technology as a self-justifying end in itself, rather than as a tool to solve real-world problems (which often have social dimensions) that's not a useful distinction. Technology is pointless unless it accounts for the social dimensions.
Technically, self-signed HTTPS is more secure than plain HTTP, but only by a small margin.
In certain circumstances (e.g. a major bank or e-commerce site which could be a juicy enough target to attract sophisticated attacks) HTTPS with a self-signed certificate is actively suspicious and warrants a warning. Your browser can't distinguish these from circumstances in which encryption alone is adequate.
HTTP is just plain insecure, and there shouldn't be any expectation of security. Also bear in mind that some (most?) browsers do, by default, warn you if you submit a form over a plain HTTP connection (although everybody then clicks "don't show this message again" - a true nanny society wouldn't give you that option, but you have to draw the line somewhere).
...and on a practical level, most current HTTPS sites (a) do have a trusted certificate and (b) use HTTPS specifically because they are going to collect some sensitive information, so "HTTPS without trust" is a fairly sensible threshold to start warning people without drowning them in warnings.
So, why not visually display both self-signed HTTPS and HTTP the same, instead of marking one in bright red?
Because some people will think "https means secure, right?" and need to be actively warned when it is not.
Then change the padlock with an open door for HTTP, a close door for self-signed HTTPS and a packlocked door for certified HTTPS?
That violates "keep it simple, stupid". You're still designing for someone like you, who knows and cares about the distinctions, rather than a random user.
The best message for random users is still "don't use self-signed https sites unless you understand the risk".
Wow, the end-user are warned as if it is more dangerous than plain HTTP site!
Yes, a self-signed https connection can be more dangerous than a plain http one if you see the "https" or the "golden padlock" and assume you have a secure connection.
You're confusing a specific tool (encryption) with the job (a browser establishing that a connection is sufficiently secure to justify displaying the "golden padlock" that non-technical users are told to look for before they enter their credit card details).
To do the job properly the browser needs encryption and some way of confirming the identity of the remote site. In the general case, encryption alone is not secure.
You may have a specific application in which you judge encryption alone to be sufficient (e.g. setting up a login for your blog so you can remember user preferences) but for other applications it is inadequate (you wouldn't log in to an e-banking site if it used a self-signed certificate, would you?) Plus, if you are a webmaster, even if you are capable of making that distinction yourself, you don't have the right to decide, on behalf of all your users, that they should trust you.
Now, the certificate-signing system is a million miles from perfect (as TFA shows) and its probably the weakest link in https, but identity verification and "trust chains" are always going to be much messier than pure encryption, and its the best we have and/or that people are prepared to put up with. "Encryption + certificate signed by a trusted authority" is the "least worst" criteria we currently have for telling a non-technical user that their connection is "secure".
A more rational mechanism should be telling users the truth honestly, i.e. "this site's traffic is encrypted and the authority is promised by xxx.com, or if self-signed, self-proclaimed"
Let's translate that message into how a typical browser user would understand it:
"This site's tetrion beam is modulated by an inverse tachyon pulse created by reversing the polarity of the neutron flow in the Heisenberg compensator. Abort/Retry/Ignore?"
...and from that, is supposed to decide whether they can safely type in their credit card number? Of course not - the best you can hope for is to educate them to "look for the secure connection icon". In that case, the only responsible advice that a browser can give about an unsigned certificate is "don't trust this site unless you understand the risks".
Because Apple prevents competition with legal threats.
...and if they hadn't, they'd be getting legal threats from the recording industry, who (at the time) only allowed Apple to sell their music on the promise of secure DRM. Providing alternate ways to sync music to the iPod circumvents this. That's changed for music - but the issue has now moved on to video and software.
The monopoly/cartel here is not Apple, but the recording industry, who were trying to force DRM on the public. The trouble is with DRM - unlike encryption - is that its very hard to implement in an "open" way, because if the user has access to the code, they can extract an unencrypted version. Actually, DRM is pretty futile full stop.
Please remember when all that was happening Apple was alive and well selling desktop computers, and Linux had a huge share of the server (particularly web server) market and a sliver of the desktop market.
In the late 90s, if you walked into a typical computer store, or picked a random online/mail-order reseller you'd usually find all of the desktop computers came with Windows, and all the software was for Windows (in larger stores there may have been an out-of-date Mac and a boxed copy of Office for Mac). If you asked the assistant about installing Linux you'd probably get some bullshit about voiding the warranty, or, more likely, a blank stare (if you were really lucky, an out-of-date copy of Red Hat on the software shelf). If you picked up a magazine with "Personal Computer" in the title you'd find 2 column inches on Mac, 2 column inches on Linux and the rest of the magazine about Windows PCs. If a software ad didn't mention what operating system it ran on, they meant Windows. Most of the cheaper peripherals only worked with Windows. Then there were all the websites which only worked properly on Internet Explorer.
The digital audio player market has never been like that - apart, maybe, for a short time after the iPod's launch I've always seen a reasonable range of non-iPod "MP3" players on offer, even more so if you count things like car stereos and CD/DVD players with "MP3" playback. Even 3rd-party speakers with iPod docks tend to have audio inputs for other devices. Any nascent iPod monopoly was ended once and for all when phones started to offer digital music (I suspect this was the real reason Apple made the iPhone). Apple's iPod/iPhone/iTunes may be market leaders, but it only looks like a monopoly when you start narrowing the definition to e.g. "touch screen portable audio devices over $200".
Its hardly surprising that Apple have a brief "monopoly" when they invent (or, more accurately, successfully market) a new sub-genre of device or service. Android is now doing well against iPhone, and its only really in the last year that Android devices started to bear comparison with the iPhone (I have an 18-month old Android phone and, believe me, it doesn't compare). It looks like its going to be another year before Android tablet makers "get it" and start competing with iPad - and then that will stop looking like a monopoly.
Ripping from a CD is not illegal in any way shape or form if you own the CD and rip it for your own use.
It is in some countries, e.g. here in the UK, although everybody realises it is stupid, I don't think anybody has ever been prosecuted and there is talk of fixing the law.
However, everybody ignores the law so, yes, buying a CD and ripping it is, and always was, a perfectly viable "competitor" to iTunes.
...once they get all the bugs out of the system.
With unencrypted data mallory can merly evesdrop. Evesdropping is easy and safe.
That's a bogus comparison - the insecurity of plain http is irrelevant. If the user has gone to a "https" site and/or if they see the "secure" indicator on their browser then they are expecting a secure connection.
A https connection without identity verification is less secure than a https connection with self-signed certificates - the browser has to "explain" this to non-technical users.
You're looking at this from the perspective of a power user who understands what is going on. Browsers are written for non-techies who, at best, have been told "look for the golden padlock". Since the browser can't tell a bank from a blog, the only responsible thing it can do is tell the user that the connection is untrusted.
All good points, except perhaps that the expense of certificates is not an issue for any business, even small ones
You've obviously never worked in a large, penny-wise-dollar-foolish, organization, where, if a $50 certificate hasn't been costed into a project and/or if your pointy-haired boss doesn't think its necessary and/or if you have to contact the legal department to produce the necessary confirmation of authority documents and/or the provider wants a credit card number and isn't on the approved suppliers database, then it might as well cost $50,000,000,000*. That can be particularly awkward if you want your site to keep working after the end of a project.
(* Slight exaggeration to account for the emotional distress of dealing with the bureaucracy).
THe problem is that the browsers persist under the myth that certs can ONLY be used for proving the identity of a host; and completely disregard the fact that an equally valid and completely unrelated task is traffic encryption.
The trouble is, identity checking and encryption are inseparable.
Public key encryption doesn't allow Bob to securely exchange data with Alice: it allows Bob to securely exchange data with someone claiming to be Alice who has given Bob what she claims to be Alice's Public Key.
Without some way for Bob to verify that the person claiming to be "Alice" is, indeed, the real Alice that's about as much use as an ashtray on a motorbike.
Where self-signed certificates are useful is when you've independently verified that the site you are connecting to is genuine (translation: you have crossed your fingers and decided that your piss-ant little site is not interesting to the black hats) - but the browser can't know that you've done that. The only responsible thing the browser can do is warn you that (as far as it is concerned) the connection could still be insecure before displaying the "secure connection" symbol.
If you're using self-signed certificates then you need to be in close enough touch with your users to reassure them about the browser warnings. If you have too many users for that to be practical then you shouldn't be using self-signed certificates. Otherwise, you're acting like my bank, who cold call me and then wonder why I won't answer their security questions - they know they're genuine, but they can't get it into their heads that the customer doesn't know, and shouldn't assume, that.
...but all that saliva spoils the taste of the chlorine, urine, dead skin cells and dilute human faeces...
A more standards compliant IE is always to be welcomed. What should not be welcomed is that "more" standards compliant != standards compliant.
For the sake of balance, the best that Firefox, Safari/Webkit, Opera et. al. can claim is that they are "more" standards compliant than past Microsoft efforts. There are plenty of glitches when trying to use (say) scripted SVG or more recent CSS features on multiple non-MS platforms (not to mention the current total existence failure of SVG on Android). Also, forget 3D, does any browser properly support the CSS printing control attributes (most support "page-break: before" but that's it).
Part of the problem is W3C's tendency to produce late, hard-to-implement standards with no reference implementations (including some complete turkeys like CSS).
Things like web workers & WebGL are not implemented in IE9 which is quite disturbing.
A quick check suggests that WebGL is only currently available in Chrome (ignoring development versions of other browsers, where it may or may not be enabled in the next release). Web workers don't seem to be available in Android/iOS (and sounds like just the sort of thing that Apple will take exception to!)
However, assuming that the other browsers will get their act together soon, this time round, the joke could be on Microsoft. This time, the tablet/phone market is huge - particularly for the sort of casual games WebGL could be used for - and MS barely have a toe-hold in it. If MS makes developers choose between supporting IE and supporting iOS/Android then (given other browsers are available for Windows) they might not like the result.
no wonder samsung is finding it difficult to compete with its 1gb ram tablet with a 2mp front cam and an 8mp rear cam, 1080p recording, dual core graphics, dual core cpu.
So why don't Samsung produce a camera with less RAM (the iPad 1 seems to work fine with 256MB) a VGA front cam (more than good enough for video calling) and a 720p rear cam (why the fsck would you want to record 1080p through a pinhole lens on a device with limited internal storage or take 8MP photos on a slab which is ergonomically hopeless as a camera?) Making sure it has the latest version of Android (i.e. one actually designed for tablets) would be a good idea, as would not choosing a lame 7" form factor (16:9 to boot) that makes it too big for a phone and too small for a tablet.
If devices like the XOOM and Galaxy Tab were undercutting Apple and had these higher specs then yes, that ought to be a winner (more RAM/better Cameras is certainly nice to have) but they're not. Nor are they going to get anywhere until Android Honeycomb is out and stable.
However, I do wonder if Samsung/MOTO's problem is that they are pricing their tablet offerings according to the mobile phone business model: inflate the RRP so that carriers can offer big discounts with contracts.
...and copy the sleek design to create a product that is equally appealing to the eyes and twice or three times as powerful?
Ignoring the "economy of scale" issue (Apple orders displays, Flash etc. in huge quantities to get low prices) how do you make it twice or three times as powerful and still use the same parts?
Faster processors/graphics cost more. They generate more heat (so you can't pack them in as tightly) and they use more power (so you have to make the battery bigger or sacrifice battery life).
Higher-res cameras cost more, and probably use more power/generate more heat to boot. They're usually less sensitive (less light falls on each pixel) which means poorer low-light performance, or more amplification (more noise, more power, more heat => even more noise) or built-in illumination (more power/heat). Higher-quality cameras need higher-quality lenses which occupy more space.
Many of the "improvements" that Apple critics ask for also occupy more space or consume more power: more USB/SD/video connections = more space occupied by connectors and their internal cables and daughterboards + more complex and expensive assembly. Removable battery = user-proof internal battery connectors, extra protection to stop users damaging innards when replacing battery (more space, weight), need to make the battery rigid and safe to handle outside the case (more space, weight, less volume for battery) user-removable back (more space, weight...).
Sorry to burst your applesauce bubble, but 512mb ram is hardly ample in 2011.
Thanks for the valuable info. Without your wisdom, how would I know that the 256MB RAM on my iPad 1 was so pitifully inadequate?
On other systems, users would know that they had inadequate RAM due to the usual symptoms (machine slowing to a crawl, errors, crashes) but Evil Apple has conspired to ensure that these rarely happen on the typical iPad, fooling customers into think that, because their device runs perfectly, they have adequate RAM.
The rascals! I feel soiled.
How would you like to run photoshop in a browser? That's a good test for how close the browser is to replacing the desktop. For myself, I also try to think of what it would be like to get a programming environment going from a browser. Right now, it's not a pleasant thought.
The point is not the browser - we're getting to the point where you can implement almost anything in JavaScript/DOM with, maybe, some server-side scripting thrown in. Even without the browser, large software suites are getting monolithic. Photoshop is part of a huge "creative suite" with its own workflow tools and plug-in ecosystem, a graphic artist need never go near the desktop (and if a lightbox application serves your needs better than a regular filing system, why should they?) . Eclipse is another example where you could potentially handle all the workflow for a complex development job within Eclipse (again, why browse your work by file when its better organised by class/object?) - heck, you could say the same for EMACS - and either of those could be implemented within a browser. The last time I played with this - a cloud/browser-based IDE it looked promising (and rather sensible for collaborative projects).
I think you've hit the nail on the head, there, although I'm not sure that its all about the browser. In fact, I think the desktop only ever truly lived on Mac and a few minority systems (Acorn RISC-OS is a good example in which the desktop became really central).
In the early days, a major (unsung) influence of the desktops on Mac and other systems was that it standardised the user interface. Before then, everytbody (Wordstar, Word Perfect, Lotus etc.) invented their own UI paradigm and even tried to prevent others copying it via look-and-feel lawsuits. With the early desktops, however, there was suddenly a single way to open, save, copy files, select blocks, copy, paste etc. and a fairly consistent menu layout across all applications (at least, per-platform - Apple were litigious towards competing desktops).
That didn't last long: pretty soon all the major software houses were trying to distinguish themselves with thier own systems of floating, dockable palettes, wizzards and unique icon designs, and started suing each other over look and feel again. In my experience, typical Windows users never really embraced the desktop (thanks partly to Windows' MDI mode) and just maximised their current application - often the only file manipulation technique they know is "Save as...". Unix/Linux suffered from the usual "Standard? Yeah we have lots of standards!" phenomenon, plus your typical *nix hacker regards a desktop as a mechanism for running 6 instances of vi and 3 xterms on the same screen.
Add to that, the tendency towards monolithic suites of programs with their own workflow management and, often, plug-in/add-on environments (MS Office and Adobe Creative Suite being the prime examples) many users who use their computer for specific jobs don't really need the desktop.
The browser/webapp is one influence - with no standard UI paradigm (or a choice of 3-4 if you used Java) everybody rolled their own. Now "Apps" and iOS/Android have brought the idea of the monolithic app, often with its own UI paradigm (although Android/iOS do provide standard widgets) well and truly to the fore.
Its a pity, really - without the Desktop/GUI as a standarsing mechanism, and application writers more worried about making their product visually distinctive than easy-to-use (and often confusing those things) computers can only get harder to use.
From TFA:
HB220 would require schools to teach students that the U.S. is a compound constitutional republic and about other forms of government such as pure democracy, monarchy and oligarchy along with political philosophies and economic systems such as socialism, individualism and free-market capitalism.
Is it just me, or does that sound a just a little bit more defensible than the spin in the summary?
I'm pretty sure a powerpc would spank an ARM on every benchmark
If you're talking about a G5 vs. your cellphone, of course - but an early-1990s desktop ARM chip vs. a early-1990s PPC would be a more interesting contest. Remember, ARM started out as a desktop chip - the first Acorn ARM systems in the late 80s smoked the competition (but, no DOS, no deal). Later they made the smart decision to focus on the mobile/low power market and leave the desktop to Intel space-heaters.
It would partly have been up to Apple to take the ARM core and team up with a chipmaker to specify a chip with the performance they needed, throwing in cache, FPUs and SIMD units to taste.
Remember the rumors when the Apple II flirted with using ARM cpus toward the end of the line when Jobs was herding the company heavily toward Motorola and the 68K?
Eh? The ARM might have been a contender for the last, education-only, gasps of the Apple II line, but Apple had committed to the 68K (with Lisa and then the Mac) back in the early 80s when the ARM was still a twinkle in Wilson & Furbers eyes.
It might have been a viable alternative to the PPC, though - that would have been interesting, but I fear it would have eventually hit the same problem: the chipmakers not keeping up with the brute-force Intel megahertz wars on the desktop because their main interests lay elsewhere (one of the factors that worked against Acorn's ARM workstations and eventually forced Apple to dump the PPC).