Most users probably don't choose to use SSL. Usually it's the server that decides it by redirecting or posting to a secure page (bad idea, anyway!) If the user types in, "mybank.com" into their address bar, the default is to try http on port 80 first. A man in the middle can intercept this, and then it's game over, anyway.
If you rely on the end-user for security, you might as well give up.
Not really, and I'm only a little irked that I was modded flamebait. People can do what they want. Doesn't affect me.
However, the simple truth is that if all you want is consistent webpages, SSI+CSS will get you that. That was the example that bryce4president used, and his solution was much heavier weight, more prone to errors, and more prone to security issues for simple consistency.
I'd say well over 75% of our clients ask for some level of Flash and in the 6+ years we've used it I don't recall ever having compatibility problems. I certainly can't say the same for the rest of these same websites.
Why are the clients dictating the tools that you use?
The problem is that people are encountering poor interface design and crap programming and blaming Flash for these problems. Blame the designers and programmers, not the application. I've encountered code provided by other companies, many times, that is complete and utter garbage.
Well, if you want to use Flash to convey any information whatsoever, then a good designer now has twice the work--convey the information in Flash, and convey the information in HTML. The existence of Flash virtually requires this, unless you make your site Flash-only, in which case, all of the complaints about Flash become valid again.
I suppose that the mere existence of Flash is not, in and of itself, terrible. But any site which uses it will either use it exclusively, or will have to duplicate effort in multiple languages. That's the problem.
1) Others debunked quite well. 2) When is relying on the server for security not possible? That's really the only time you can guarantee that a modified client isn't doing bad things. 3) Ah, but once the main page is loaded, XMLHTTPRequest lets you get smaller chunks of data than you would normally get. With JSON, you can reduce that even further. And nothing's stopping you from writing your own codec to send information down the pipeline.
Slashdot is a great example of AJAX making things lighter. With Discussion2, I don't have to download the entire Slashdot page to view nested comments. I just click on the comment, and it loads the relevant data. 4) Yeah, standardization is a problem:(
If you want standardized layouts, there are much lighter weight solutions than PHP. Server Side Includes have been around for ages and will do just that. You shouldn't be calling the PHP interpreter just to have common headers and footers.
PHP started out as a templating framework and evolved into a language. It also manages to do lots of little things just a little bit differently than every other language on Earth, making it hard to really learn. Throw in some dubious design decisions (no namespaces? WTF?) and you've got something that's really just a mess.
PHP should never have been extended to do real work. It's fantastic for really simple things, but once you add in much complexity, it's the wrong tool for the job.
Every new, major instruction set has patents associated with them. The various SSEs, MMXs, etc. are all probably still patent encumbered. So while you can probably make an x86 CPU without patents, it won't have all those nifty extensions that are effectively standard these days, unless you pay royalties.
It's all relative. If I know that the certificate presented is real, then the self-signed cert is better than the CA cert. There's nothing stopping you from running your own CA and providing the cert to your customers.
There's overhead associated with encrypting HTTP connections. It may not be much, but it's there. On a service with millions of users, it would definitely add up.
Before Google allowed you to specify https, you could use https://mail.google.com/ to encrypt everything. The catch is that the AJAX code for Gmail would try https first, but fall back to http if it couldn't connect securely. All an attacker had to do with muddle with the https connections and he was golden.
I think that in Google's case, the SID lasts indefinitely, and it refreshes each time it was used.
A lot of this came out last year, and the upshot was that an attacker could get permanent access to your account through this method. The only way to stop them was to get Google to kill the session. Good luck with that.
He appears to be a skilled troll. He refuses to point out anything that he actually doesn't like about Kubuntu--just that "it isn't marketed to me" and "it isn't up to par." No specifics, and he gets people to beg for specifics because he's playing the injured party. It's a masterful stroke, frankly.
Of course encrypting the file before hand is an option but then you lose the ability to browse the files without a special viewer that can read the encrypted files or decrypting them first.
One of his four design requirements was "secure backup (encrypted and signed) to non-trusted FTP site"
So yeah, it sounds like he means to leave the file encrypted on the remote host. Almost as if he doesn't trust the remote host, but wants to use its storage for backups.
If I buy something (from Apple) am I not allowed to re-sell it? In the US, we have the First Sale doctrine. I can certainly sell the copy I purchased.
I guess that might throw a wrinkle in the GPL, though. I wonder what stops me from "selling" a GPL binary that I received for free without following the terms of the GPL? Perhaps I would have to prove that I downloaded and received a new license for each new copy that I transfer to a new user.
Evidently now they distribute GPL software in order for end users to be able to self-restore their systems. In that case are they also hosting the source, because that is definitely a clause in the GPL regarding "distribution" of copies.
Where did you read that? All I saw in the article was that they are providing Leopard discs to help the users reinstall.
Individual clauses in a license agreement may be stricken without invalidating the entire agreement. With the Apple EULA, people are concerned with the "non-Apple branded computer" bit of the agreement. Is that legal? Maybe, maybe not.
This isn't an issue about Licenses in general because copyright still applies even if both the Apple EULA and the GPL were stricken. The difference is that if the entire Apple EULA were stricken, I'd still be able to install and use OS X. Although the EULA purports to grant a license to install and use, this license is not necessary to legally install and use the software. Others have explained why (with citations) throughout these comments.
If the GPL were stricken, people would still be able to install and use GPL software. Distribution would no longer be allowed, though, because this right is reserved (by default) and without an explicit license granting the right to distribute, the person receiving that bit of software simply has no right to do so.
To sum it up, if I legally obtain a piece of copyrighted software, I have the right to use that software, but I do not have a right to distribute that software. But it's all irrelevant because this isn't an attack on EULAs/licenses in general, but upon specific terms of the license.
Interestingly, they don't use the whole BSD kernel. Most of what they got from BSD was the userland--the applications you associate with Unix. The kernel is XNU, which has elements of Mach, BSD (for the IPC and a few other POSIX elements), and some other stack that they use for device drivers.
I don't know. I thought that first sale had to do with purchased copies of works. Licenses are different beasts. If a software company can convince a judge that no sale took place, only licensing, then they might be able to circumvent the First Sale doctrine.
I had a Windows Mobile 5.0 smartphone before I bought my iPhone 3G. I found better firmwares than the one my carrier provided, bringing it up to 6.0 in the process, and stripping out a lot of cruft.
My experiences: I'd never buy a Windows Mobile device that I couldn't customize with alternate firmware. The main reason for this is that I found myself having to hard reset fairly frequently with my carrier's firmware. This wasn't the case with the alternate versions, but this is as likely to be due to the cruft-removal as anything else. That said, if I/did/ need to do a hard reset while I was away from my computer, it took much less time to bring my phone back to usability when the applications I wanted were all pre-installed.
Windows Mobile certainly has a few advantages over the iPhone. My biggest new gripe is that the iPhone's vibrate function is simply terrible, and there's no official way to extend it. In the stock configuration, it vibrates for 0.4 seconds. If my phone is on silent, and in my pocket, I'm just not going to feel that. You can modify some system files on the device to change the vibrate pattern and duration, but that requires jailbreaking. With Windows Mobile, the vibrate was longer, you could change it with a registry edit, and you could install third-party software which managed the vibration for you, all without having to modify the firmware. So that's one point for Windows Mobile.
What Windows Mobile doesn't give you is a damned decent browser. Pocket IE is a joke. It's slow, renders most websites terribly, crashes a lot, and implements a small subset of javascript (it threw errors on probably 25% of the sites I regularly visit.) There are alternate options from third parties, all with a different set of drawbacks (ranging from poor font scaling to being non-free, to simply being so slow as to be nearly unusable, in the case of Minimo.) The web browser was the number one reason I wanted an iPhone. It's a joy to use compared to every Windows Mobile option I could find.
Pocket Outlook is pretty lousy, too. Its IMAP support feels like it's half-finished, and features that most mail clients (even phone mail clients) support, such as setting an IMAP prefix, simply don't exist. I remember having a hard time even changing the port I wanted to use; ultimately, I resorted to setting up a proxy on another server so that I could run multiple IMAP servers on my main box. Third-party support is lacking. An application called Qmail will work, though getting SSL support is a pain, and all of the documentation is either incomplete or in Japanese. Even when you get it all working, the interface is clunky. Flexmail was pretty good, but required a purchase. iPhone's mail application isn't perfect--it's nowhere near a joy to use, in my opinion, but it's the best of the Windows Mobile options.
Don't even get me started on Windows Media Player for Windows Mobile. I gave up on that and found some thankfully free Winamp clone.
The last point, I'll give to Windows Mobile. Third party support is far better, because third party software has access to all of the phone's features. But you know what? The only application that the iPhone doesn't come with by default, and which I used for any significant amount of time on my WM phone is SSH. And frankly, because of the screen size, I didn't do that as much as I thought I would when I bought the phone.
So there you have it. The comparison of the iPhone vs. Windows Mobile from a user with a history of PDA and Smartphone use, and with actual examples of the reasons that I prefer the iPhone.
Re:Re-usable libraries
on
Bash Cookbook
·
· Score: 1
That's where I was coming from in some of my replies to this guy. It sounds like a really neat little hack, and I'd love to see the implementation, but using those libraries instead of learning Perl seems more like a bandage.
I understand the motivation. Presumably, these junior admins know bash, and bash has shortcomings, so if you can fix those shortcomings, there's a small gain in efficiency. It's just that in the long run, for both the company and the individual, it would probably be worth learning Perl.
Re:Re-usable libraries
on
Bash Cookbook
·
· Score: 1
They're learning the syntax of your library. They could be learning the syntax of Perl. They could learn both, but they're duplicating effort then.
I'm not knocking making the libraries itself, but it just seems like time spent learning your library (for the job) could be spent learning something which is more universally used.
Re:Re-usable libraries
on
Bash Cookbook
·
· Score: 2, Insightful
That sounds pretty neat and all, but wouldn't you be better served training people on a language which has these constructs built in? The juniors are still having to learn new programming syntax--only instead of learning Perl, they're learning something that's not used anywhere else in the world.
Slashdot Mirror
Most users probably don't choose to use SSL. Usually it's the server that decides it by redirecting or posting to a secure page (bad idea, anyway!) If the user types in, "mybank.com" into their address bar, the default is to try http on port 80 first. A man in the middle can intercept this, and then it's game over, anyway.
If you rely on the end-user for security, you might as well give up.
$100/year? You're crazy. Try in the $30 range.
Basically, a cert's a cert. Unless you're buying into the extended validation certs, you really might as well go for the lowest bidder.
Not really, and I'm only a little irked that I was modded flamebait. People can do what they want. Doesn't affect me.
However, the simple truth is that if all you want is consistent webpages, SSI+CSS will get you that. That was the example that bryce4president used, and his solution was much heavier weight, more prone to errors, and more prone to security issues for simple consistency.
I'd say well over 75% of our clients ask for some level of Flash and in the 6+ years we've used it I don't recall ever having compatibility problems. I certainly can't say the same for the rest of these same websites.
Why are the clients dictating the tools that you use?
The problem is that people are encountering poor interface design and crap programming and blaming Flash for these problems. Blame the designers and programmers, not the application. I've encountered code provided by other companies, many times, that is complete and utter garbage.
Well, if you want to use Flash to convey any information whatsoever, then a good designer now has twice the work--convey the information in Flash, and convey the information in HTML. The existence of Flash virtually requires this, unless you make your site Flash-only, in which case, all of the complaints about Flash become valid again.
I suppose that the mere existence of Flash is not, in and of itself, terrible. But any site which uses it will either use it exclusively, or will have to duplicate effort in multiple languages. That's the problem.
1) Others debunked quite well. :(
2) When is relying on the server for security not possible? That's really the only time you can guarantee that a modified client isn't doing bad things.
3) Ah, but once the main page is loaded, XMLHTTPRequest lets you get smaller chunks of data than you would normally get. With JSON, you can reduce that even further. And nothing's stopping you from writing your own codec to send information down the pipeline.
Slashdot is a great example of AJAX making things lighter. With Discussion2, I don't have to download the entire Slashdot page to view nested comments. I just click on the comment, and it loads the relevant data.
4) Yeah, standardization is a problem
If you want standardized layouts, there are much lighter weight solutions than PHP. Server Side Includes have been around for ages and will do just that. You shouldn't be calling the PHP interpreter just to have common headers and footers.
PHP started out as a templating framework and evolved into a language. It also manages to do lots of little things just a little bit differently than every other language on Earth, making it hard to really learn. Throw in some dubious design decisions (no namespaces? WTF?) and you've got something that's really just a mess.
PHP should never have been extended to do real work. It's fantastic for really simple things, but once you add in much complexity, it's the wrong tool for the job.
Every new, major instruction set has patents associated with them. The various SSEs, MMXs, etc. are all probably still patent encumbered. So while you can probably make an x86 CPU without patents, it won't have all those nifty extensions that are effectively standard these days, unless you pay royalties.
I think this is wrong.
Recent versions of OpenSSL have support for TLS. I think it's mod_ssl explicitly which does not.
You can run lighttpd with a recent OpenSSL to get SNI.
Until Apache+OpenSSL supports Server Name Indication (coming soon, supposedly), we'll have some problems with every website having encryption.
Sure, you could use mod_gnutls, but that's pretty untested from what I understand. Is anyone out there actually using it?
It's all relative. If I know that the certificate presented is real, then the self-signed cert is better than the CA cert. There's nothing stopping you from running your own CA and providing the cert to your customers.
There's overhead associated with encrypting HTTP connections. It may not be much, but it's there. On a service with millions of users, it would definitely add up.
Before Google allowed you to specify https, you could use https://mail.google.com/ to encrypt everything. The catch is that the AJAX code for Gmail would try https first, but fall back to http if it couldn't connect securely. All an attacker had to do with muddle with the https connections and he was golden.
I think that in Google's case, the SID lasts indefinitely, and it refreshes each time it was used.
A lot of this came out last year, and the upshot was that an attacker could get permanent access to your account through this method. The only way to stop them was to get Google to kill the session. Good luck with that.
He appears to be a skilled troll. He refuses to point out anything that he actually doesn't like about Kubuntu--just that "it isn't marketed to me" and "it isn't up to par." No specifics, and he gets people to beg for specifics because he's playing the injured party. It's a masterful stroke, frankly.
Of course encrypting the file before hand is an option but then you lose the ability to browse the files without a special viewer that can read the encrypted files or decrypting them first.
One of his four design requirements was "secure backup (encrypted and signed) to non-trusted FTP site"
So yeah, it sounds like he means to leave the file encrypted on the remote host. Almost as if he doesn't trust the remote host, but wants to use its storage for backups.
Subscriber IDs are overrated.
If I buy something (from Apple) am I not allowed to re-sell it? In the US, we have the First Sale doctrine. I can certainly sell the copy I purchased.
I guess that might throw a wrinkle in the GPL, though. I wonder what stops me from "selling" a GPL binary that I received for free without following the terms of the GPL? Perhaps I would have to prove that I downloaded and received a new license for each new copy that I transfer to a new user.
Evidently now they distribute GPL software in order for end users to be able to self-restore their systems. In that case are they also hosting the source, because that is definitely a clause in the GPL regarding "distribution" of copies.
Where did you read that? All I saw in the article was that they are providing Leopard discs to help the users reinstall.
Individual clauses in a license agreement may be stricken without invalidating the entire agreement. With the Apple EULA, people are concerned with the "non-Apple branded computer" bit of the agreement. Is that legal? Maybe, maybe not.
This isn't an issue about Licenses in general because copyright still applies even if both the Apple EULA and the GPL were stricken. The difference is that if the entire Apple EULA were stricken, I'd still be able to install and use OS X. Although the EULA purports to grant a license to install and use, this license is not necessary to legally install and use the software. Others have explained why (with citations) throughout these comments.
If the GPL were stricken, people would still be able to install and use GPL software. Distribution would no longer be allowed, though, because this right is reserved (by default) and without an explicit license granting the right to distribute, the person receiving that bit of software simply has no right to do so.
To sum it up, if I legally obtain a piece of copyrighted software, I have the right to use that software, but I do not have a right to distribute that software. But it's all irrelevant because this isn't an attack on EULAs/licenses in general, but upon specific terms of the license.
Though they have made moves against people explaining how to make a Hackintosh. Realistically, that's all they can do.
Interestingly, they don't use the whole BSD kernel. Most of what they got from BSD was the userland--the applications you associate with Unix. The kernel is XNU, which has elements of Mach, BSD (for the IPC and a few other POSIX elements), and some other stack that they use for device drivers.
I don't know. I thought that first sale had to do with purchased copies of works. Licenses are different beasts. If a software company can convince a judge that no sale took place, only licensing, then they might be able to circumvent the First Sale doctrine.
I had a Windows Mobile 5.0 smartphone before I bought my iPhone 3G. I found better firmwares than the one my carrier provided, bringing it up to 6.0 in the process, and stripping out a lot of cruft.
My experiences: I'd never buy a Windows Mobile device that I couldn't customize with alternate firmware. The main reason for this is that I found myself having to hard reset fairly frequently with my carrier's firmware. This wasn't the case with the alternate versions, but this is as likely to be due to the cruft-removal as anything else. That said, if I /did/ need to do a hard reset while I was away from my computer, it took much less time to bring my phone back to usability when the applications I wanted were all pre-installed.
Windows Mobile certainly has a few advantages over the iPhone. My biggest new gripe is that the iPhone's vibrate function is simply terrible, and there's no official way to extend it. In the stock configuration, it vibrates for 0.4 seconds. If my phone is on silent, and in my pocket, I'm just not going to feel that. You can modify some system files on the device to change the vibrate pattern and duration, but that requires jailbreaking. With Windows Mobile, the vibrate was longer, you could change it with a registry edit, and you could install third-party software which managed the vibration for you, all without having to modify the firmware. So that's one point for Windows Mobile.
What Windows Mobile doesn't give you is a damned decent browser. Pocket IE is a joke. It's slow, renders most websites terribly, crashes a lot, and implements a small subset of javascript (it threw errors on probably 25% of the sites I regularly visit.) There are alternate options from third parties, all with a different set of drawbacks (ranging from poor font scaling to being non-free, to simply being so slow as to be nearly unusable, in the case of Minimo.) The web browser was the number one reason I wanted an iPhone. It's a joy to use compared to every Windows Mobile option I could find.
Pocket Outlook is pretty lousy, too. Its IMAP support feels like it's half-finished, and features that most mail clients (even phone mail clients) support, such as setting an IMAP prefix, simply don't exist. I remember having a hard time even changing the port I wanted to use; ultimately, I resorted to setting up a proxy on another server so that I could run multiple IMAP servers on my main box. Third-party support is lacking. An application called Qmail will work, though getting SSL support is a pain, and all of the documentation is either incomplete or in Japanese. Even when you get it all working, the interface is clunky. Flexmail was pretty good, but required a purchase. iPhone's mail application isn't perfect--it's nowhere near a joy to use, in my opinion, but it's the best of the Windows Mobile options.
Don't even get me started on Windows Media Player for Windows Mobile. I gave up on that and found some thankfully free Winamp clone.
The last point, I'll give to Windows Mobile. Third party support is far better, because third party software has access to all of the phone's features. But you know what? The only application that the iPhone doesn't come with by default, and which I used for any significant amount of time on my WM phone is SSH. And frankly, because of the screen size, I didn't do that as much as I thought I would when I bought the phone.
So there you have it. The comparison of the iPhone vs. Windows Mobile from a user with a history of PDA and Smartphone use, and with actual examples of the reasons that I prefer the iPhone.
That's where I was coming from in some of my replies to this guy. It sounds like a really neat little hack, and I'd love to see the implementation, but using those libraries instead of learning Perl seems more like a bandage.
I understand the motivation. Presumably, these junior admins know bash, and bash has shortcomings, so if you can fix those shortcomings, there's a small gain in efficiency. It's just that in the long run, for both the company and the individual, it would probably be worth learning Perl.
They're learning the syntax of your library. They could be learning the syntax of Perl. They could learn both, but they're duplicating effort then.
I'm not knocking making the libraries itself, but it just seems like time spent learning your library (for the job) could be spent learning something which is more universally used.
That sounds pretty neat and all, but wouldn't you be better served training people on a language which has these constructs built in? The juniors are still having to learn new programming syntax--only instead of learning Perl, they're learning something that's not used anywhere else in the world.
Is this a way of enforcing loyalty? :)