I'll have to check that one out. I've been debating getting some more screens for my desktop now that I'm using a DisplayPort capable graphics card. Granted, if the IPS236V doesn't support displayPort then I'd probably just end up shelling out the little extra for more of my current HP ZR24Ws.
Yeah, but the actual Greek words aren't so clear. The word for day also can translate as age. The word for morning can translate as soon or dawn and the word for evening can translate as twilight. Roughly they mean start and stop to an age. It's still a somewhat poetic read, sure, but Jesus himself spoke in parables that clearly were not literal events.
And don't get me wrong, personally, I still am fairly convinced that the Biblical creation story can be accurate as recorded, but I don't think that evening and morning have the same meaning prior to the existence of conventional evenings and mornings. It really doesn't fail to match up with our current understanding of how we think things happened, particularly if you consider it as a poetic recording of a vision given to whoever actually wrote it down (since obviously they weren't there themselves at the time).
I don't actually run in to a problem with taking everything as actual historical description until Noah, which I have trouble explaining the resultant movement of land masses and the rising of mountains necessary to have had it be possible to flood the entire Earth within what would appear to have to be the geologic time scale. Continental drift presents a far larger problem to solve than the big bang theory or evolution ever dreamed of presenting, but it unfortunately gets overlooked and has almost no discussion in any circles I've come across.
Yeah, this also makes it far more clear how the concepts of eternity or God being all knowing could make sense. If you could see time as we see things in three dimensions, then it becomes trivial to see the "future". A lot of the Bible makes far more sense if you assume that God isn't bound by time. (And really, I don't think it is much of an assumption to make.)
As a Christian, I have to say the biggest frustration I find is the fact that so many Christians are so insistent on 6 24 hour days when there wasn't even the concept of a modern day for the first several days. Even more direct, Jesus said he would come again "soon". I'm pretty sure that rules out the idea of our idea of time being anything like what God considers time so I have no idea why someone would insist it MUST be 6 24 hour days. Could God have made things look like they do and do it in 6 days if he's all powerful? Sure, but why would he. It doesn't make sense and there isn't anything Biblical that says that it is 6 24 hour days either.
I think he might be getting at the fact that children are the best learners and rapidly the ability to learn starts to fall off making it more difficult to pick up new things.
Physics doesn't dictate how fast a router functions or how much signal processing time may be required on the satellite in order to get the higher speeds. That said, a further read of the article indicates it was online speed tests, not a direct ping to first step, so 600ms appears to be accurate. This makes this satellite a huge improvement from previous ones. Latency was closer to a second or more on many previous bi-directional satellite systems.
Yeah, tablets is actually where I had seen it the most. I was surprised when I saw that my Asus Transformer (which I consider a fairly cheap tablet) had a S-IPS panel in it. I do a fair bit of video, photography and graphics design work and used to take flack for lugging my $150, 53 pound Viewsonic A90F+ CRT to conferences for the color accuracy. When it finally died an unfortunate death, I had to end up dropping $600 to get a 24 inch HP S-IPS screen with the same vertical resolution though. Apparently costs are coming down though. That same S-IPS panel is apparently now only $350 or so. Back when I got the HP, nobody bothered advertising what kind of panels were in monitors either so you had to go digging through websites that looked in to the panel suppliers to figure out what you were getting.
Thanks for the link. Also, I know that XML wasn't a popular format (if it was even used at all) when PSD was created, but it could have been replaced since then if there was a need for it. That said, I don't think their is and your link to the file format even further proves what I was trying to get at (that the file format is not a means of vendor lock in.)
I wonder why that wasn't noticeable pretty quickly. One time my wheel was torqued a little when I was putting the lugs back on and the vibrations from the thing made it obvious there was a problem. I pulled over, readjusted the wheel to get it properly set and had no more problems. Granted, I suppose with only one lug on by half a turn it might have come off before he noticed.
It depends what they pinged. If they pinged the satellite itself, then the satellite's link to the internet would have the same ping. (Client to Sat, Sat to Base, Base to Sat, Sat to Client for a full round trip) I haven't read the article yet though, so I'm not sure if they might have mentioned what they pinged specifically.
It can actually be read in most Adobe products (such as Premiere and After Effects and InDesign for example). I agree on it having nothing to do with being a vendor lock-in device though. It was simply a cleaner way to encapsulate all the details of a Photoshop project in to a single file. Sure the format could have been to save in a standard image format for each layer and have some XML data to describe the details and then maybe put them all in some type of file compression like docx does, but that would probably have performance impacts that are undesirable when working with very large image files.
I suppose you could argue that not releasing the spec makes it a vendor lock in, but the format is also specific to a number of Adobe features. If the system opening the file didn't have exact equivalents of the algorithms in Photoshop, then the file would not open looking like the original artist had intended.
Aren't most displays still TN panels anyway with only 6 bit color? Granted I have noticed there seems to be a rise in the number of S-IPS and S-PVA monitors on the market so that trend appears that it may finally be changing.
It does not have CISCO IPSEC support. This is likely what the blogger was referring to when he mentions integrated IPSEC client. There are alternatives with a tun.ko capable kernel and third party VPN software, but it is a rather large pain to configure on most devices and impossible on many without custom roms. I've been trying to get it working on my GNEX but support for authenticators seems to be lacking in the third party clients that I have found.
It lacks CISCO IPSEC support, which is what many, if not most, businesses use for their VPNs. It does support AnyConnect and it supports conventional IPSEC for quite some time now though.
Yeah, but if the gifter isn't the contract holder, they wouldn't be able to buy the phone anyway unless they were paying unlocked no-contract pricing on it. That said, if someone wanted a phone any number of people could give them money for it as well. I guess the point I was trying to make is that the original poster did have a point that giving a gift of a phone isn't a bad idea in many cases and is a viable explanation for the bump. Looking at many of the people I know, particularly kids, but in many cases married adults as well, new phones tend to come on either birthdays or Christmas time and since upgrades come in increments of years, once you get a new phone around Christmas, it has a tendency to stay around Christmas.
To throw my personal thoughts in to the fray. It really depends on what you are trying to do. For slimmed down front end, I prefer PHP. If you came from a PHP background, I would expect ASP.Net's UI to be infuriating to get used to. (I also come from a very strong PHP background and the shift to ASP.NET webforms for a project at work has been a major headache.) That said, ASP.Net MVC functions much more in the PHP style that you are used to. Overall though, unless you need to have the same front end and back end, I would recommend working the front end in whatever you are the most comfortable with. If that is PHP, I don't see any reason it should cause you trouble.
As for the backend, it could be done in PHP and I've done back ends in PHP before, but you will need to either use a third party framework or write a lot from the ground up. My preference has been to build from the ground up, but I've also typically worked on very specialized solutions. This is where ASP.Net really shines though. In terms of data handling and providing web services to back your site. C# and.Net offer a lot of very powerful tools and nice enterprise compatibility. The debugging tools are also excellent. If you are using MSSQL to back the project, then it is almost a no brainer, but my understanding is that MySQL and Postgres support isn't bad either. ASP will also let you easily switch the type of web service you are using by simply swapping out the interface or in some cases, simply updating a config file.
If it is just your personal site though, then again, PHP will probably serve you just fine, particularly if your hosting provider doesn't support ASP.Net.
I would love to see more information about how the statistics were gathered. How would using Firefox, Opera or Skyfire impact this? Does this really only mean that the majority of Android users don't use their built in browser when using the web? I know I frequently use either Firefox or Skyfire, though I've started to use the built in browser with ICS more. Comparatively, my impression at least is that the vast majority of users on iPhone/iPad use Safari.
In a family though it makes sense. My spouse got me a Galaxy Nexus for Christmas and her cousin (like 8) got his first cellphone from his parents for Christmas.
Right, but if I hadn't been to that version of that page before and something I hadn't loaded before tried to run I would STILL get a UAC prompt because that data file isnt hashed.
The entire data file doesn't have to have been run, just authorized. If it is unaltered, it could have run the last time when the file was run and the damage would be done. That said, one thing I realize you would give up is that once compromised by a legit app, there would need to be a mechanism checking entry points to make sure a new hashed exe isn't written and loaded directly in the future.
I'll take a look for the posts you mentioned. Most of my reading was pre Vista.
A data file can't do anything without being loaded in to memory to be executed on. As long as you are hashing everything loaded in (including files) then you should be ok against data files. This would limit the practicality in terms of things that have to work with data files, but would work great for certain tools and anything being used with common files. There is also the fact that if the app is known to behave well, then in many cases, any data file that is user requested is going to be irrelevant and automatically opened files should have existing hashes after the first few runs. If the data file is user loaded, then pre-authorized or not, it would still be a problem (the one exploit scenario would be if someone could programatically call the authorized executable passing in a file to open, so that could be a flaw).
I disagree with what the purpose of UAC was. As I recall, the stated purpose for UAC was to prevent malware from being able to get elevated privileges without the user having to authorize it. It was supposed to be a means of protecting the user from unauthorized software doing bad things. It ended up having the side effect of making developers try to avoid doing things they didn't need to, but I never got the impression that that was MS' intent in the implementation, at least not from any of the material they were distributing to partners when they were implementing it with Vista. If you have some documentation that suggests otherwise though, I think it would be an interesting read. I don't disagree that it was an effect, I just wasn't under the impression it was even an intended one, at least not the primary intention.
I think maybe you aren't fully understanding what I am suggesting. I will attempt to clarify on a point by point basis.
1) You don't try to hash the files directly, you hash on entry in to memory. It would probably look something like this. When an app first launches and needs elevation, the UAC prompt is given. When the user approves and specified to authorize for future use, it would load in to protected memory space and hash on what is loaded in to the elevated execution. After that, it would hash anything that was loaded in to memory or that was written out from memory in the elevated state, effectively tracking the authorized activities. On future runs, if anything tried to be loaded that didn't have a hash on file, the UAC prompt would be given. This might be difficult or even impossible to do for a native app, but should be reasonably easy to do with.Net apps at least.
2) This could be addressed with a maximum level of security that the persisted authorization would give. I know my main reason for wanting to be able to do pre-authorizations is that I have several monitoring and power user tools that I use which require administrative access to do their job fully. I have these set to run on start up since I use them all the time and it is frustrating to have to repeatedly click the UAC approval every time. Situations like this are what a feature like this would be perfect for.
3) There is possibly some truth to not wanting to give an average user access to this kind of functionality, but you also have to consider that the average user typically just clicks yes anyway, particularly if it shows up a lot. If you can reduce how often it shows up and also highlight if an elevated process has changed since last run, then it could make much more effective warning when something appears to be amok. As for your claim that I don't understand it, I don't know why you feel that way. Perhaps you simply didn't understand the full concept I was presenting and how it could work. I'm not saying it would work in every situation, but even if it could work in some, it would be helpful.
Make the command line parameters used for calling part of the hash then, perhaps part of the salt of it. My argument is simply that if you can be reasonably certain that the activity being performed is the same (exactly) as an action done in the past that was permitted, then it is likely still permitted (if the user choose to say they wanted that action to be permitted in the future.) If any part of the process is different or has not been previously authorized for future privileged access then the prompt should go again. The only vulnerability I can think of would be if the hash itself was compromised with the same length file as the previous (which is theoretically doable for some hashes, but not easy).
Perhaps I misunderstood your original post then. You mentioned that a hash of the executable wouldn't help because it opens some dlls or trusted data files, but for those files to be an issue, they must be able to be modified without elevated privileges which would mean that you are compromised as soon as you legitimatly launch the app the next time. In fact, if you were to store hashes of the files, it would offer additional protection as such tampering would be detected and a prompt would be given. If you know an app is pre-authorized and it prompts for authorization without having been modified, then you know something else modified it and the executable may not be safe.
Slashdot Mirror
I'll have to check that one out. I've been debating getting some more screens for my desktop now that I'm using a DisplayPort capable graphics card. Granted, if the IPS236V doesn't support displayPort then I'd probably just end up shelling out the little extra for more of my current HP ZR24Ws.
Yeah, but the actual Greek words aren't so clear. The word for day also can translate as age. The word for morning can translate as soon or dawn and the word for evening can translate as twilight. Roughly they mean start and stop to an age. It's still a somewhat poetic read, sure, but Jesus himself spoke in parables that clearly were not literal events.
And don't get me wrong, personally, I still am fairly convinced that the Biblical creation story can be accurate as recorded, but I don't think that evening and morning have the same meaning prior to the existence of conventional evenings and mornings. It really doesn't fail to match up with our current understanding of how we think things happened, particularly if you consider it as a poetic recording of a vision given to whoever actually wrote it down (since obviously they weren't there themselves at the time).
I don't actually run in to a problem with taking everything as actual historical description until Noah, which I have trouble explaining the resultant movement of land masses and the rising of mountains necessary to have had it be possible to flood the entire Earth within what would appear to have to be the geologic time scale. Continental drift presents a far larger problem to solve than the big bang theory or evolution ever dreamed of presenting, but it unfortunately gets overlooked and has almost no discussion in any circles I've come across.
Yeah, this also makes it far more clear how the concepts of eternity or God being all knowing could make sense. If you could see time as we see things in three dimensions, then it becomes trivial to see the "future". A lot of the Bible makes far more sense if you assume that God isn't bound by time. (And really, I don't think it is much of an assumption to make.)
As a Christian, I have to say the biggest frustration I find is the fact that so many Christians are so insistent on 6 24 hour days when there wasn't even the concept of a modern day for the first several days. Even more direct, Jesus said he would come again "soon". I'm pretty sure that rules out the idea of our idea of time being anything like what God considers time so I have no idea why someone would insist it MUST be 6 24 hour days. Could God have made things look like they do and do it in 6 days if he's all powerful? Sure, but why would he. It doesn't make sense and there isn't anything Biblical that says that it is 6 24 hour days either.
I think he might be getting at the fact that children are the best learners and rapidly the ability to learn starts to fall off making it more difficult to pick up new things.
Physics doesn't dictate how fast a router functions or how much signal processing time may be required on the satellite in order to get the higher speeds. That said, a further read of the article indicates it was online speed tests, not a direct ping to first step, so 600ms appears to be accurate. This makes this satellite a huge improvement from previous ones. Latency was closer to a second or more on many previous bi-directional satellite systems.
Yeah, tablets is actually where I had seen it the most. I was surprised when I saw that my Asus Transformer (which I consider a fairly cheap tablet) had a S-IPS panel in it. I do a fair bit of video, photography and graphics design work and used to take flack for lugging my $150, 53 pound Viewsonic A90F+ CRT to conferences for the color accuracy. When it finally died an unfortunate death, I had to end up dropping $600 to get a 24 inch HP S-IPS screen with the same vertical resolution though. Apparently costs are coming down though. That same S-IPS panel is apparently now only $350 or so. Back when I got the HP, nobody bothered advertising what kind of panels were in monitors either so you had to go digging through websites that looked in to the panel suppliers to figure out what you were getting.
Thanks for the link. Also, I know that XML wasn't a popular format (if it was even used at all) when PSD was created, but it could have been replaced since then if there was a need for it. That said, I don't think their is and your link to the file format even further proves what I was trying to get at (that the file format is not a means of vendor lock in.)
I wonder why that wasn't noticeable pretty quickly. One time my wheel was torqued a little when I was putting the lugs back on and the vibrations from the thing made it obvious there was a problem. I pulled over, readjusted the wheel to get it properly set and had no more problems. Granted, I suppose with only one lug on by half a turn it might have come off before he noticed.
It depends what they pinged. If they pinged the satellite itself, then the satellite's link to the internet would have the same ping. (Client to Sat, Sat to Base, Base to Sat, Sat to Client for a full round trip) I haven't read the article yet though, so I'm not sure if they might have mentioned what they pinged specifically.
It can actually be read in most Adobe products (such as Premiere and After Effects and InDesign for example). I agree on it having nothing to do with being a vendor lock-in device though. It was simply a cleaner way to encapsulate all the details of a Photoshop project in to a single file. Sure the format could have been to save in a standard image format for each layer and have some XML data to describe the details and then maybe put them all in some type of file compression like docx does, but that would probably have performance impacts that are undesirable when working with very large image files.
I suppose you could argue that not releasing the spec makes it a vendor lock in, but the format is also specific to a number of Adobe features. If the system opening the file didn't have exact equivalents of the algorithms in Photoshop, then the file would not open looking like the original artist had intended.
Aren't most displays still TN panels anyway with only 6 bit color? Granted I have noticed there seems to be a rise in the number of S-IPS and S-PVA monitors on the market so that trend appears that it may finally be changing.
It does not have CISCO IPSEC support. This is likely what the blogger was referring to when he mentions integrated IPSEC client. There are alternatives with a tun.ko capable kernel and third party VPN software, but it is a rather large pain to configure on most devices and impossible on many without custom roms. I've been trying to get it working on my GNEX but support for authenticators seems to be lacking in the third party clients that I have found.
It lacks CISCO IPSEC support, which is what many, if not most, businesses use for their VPNs. It does support AnyConnect and it supports conventional IPSEC for quite some time now though.
Yeah, but if the gifter isn't the contract holder, they wouldn't be able to buy the phone anyway unless they were paying unlocked no-contract pricing on it. That said, if someone wanted a phone any number of people could give them money for it as well. I guess the point I was trying to make is that the original poster did have a point that giving a gift of a phone isn't a bad idea in many cases and is a viable explanation for the bump. Looking at many of the people I know, particularly kids, but in many cases married adults as well, new phones tend to come on either birthdays or Christmas time and since upgrades come in increments of years, once you get a new phone around Christmas, it has a tendency to stay around Christmas.
Does it count if we go on and on about how we WISH Duke Nukem Forever had never been released?
To throw my personal thoughts in to the fray. It really depends on what you are trying to do. For slimmed down front end, I prefer PHP. If you came from a PHP background, I would expect ASP.Net's UI to be infuriating to get used to. (I also come from a very strong PHP background and the shift to ASP.NET webforms for a project at work has been a major headache.) That said, ASP.Net MVC functions much more in the PHP style that you are used to. Overall though, unless you need to have the same front end and back end, I would recommend working the front end in whatever you are the most comfortable with. If that is PHP, I don't see any reason it should cause you trouble.
As for the backend, it could be done in PHP and I've done back ends in PHP before, but you will need to either use a third party framework or write a lot from the ground up. My preference has been to build from the ground up, but I've also typically worked on very specialized solutions. This is where ASP.Net really shines though. In terms of data handling and providing web services to back your site. C# and .Net offer a lot of very powerful tools and nice enterprise compatibility. The debugging tools are also excellent. If you are using MSSQL to back the project, then it is almost a no brainer, but my understanding is that MySQL and Postgres support isn't bad either. ASP will also let you easily switch the type of web service you are using by simply swapping out the interface or in some cases, simply updating a config file.
If it is just your personal site though, then again, PHP will probably serve you just fine, particularly if your hosting provider doesn't support ASP.Net.
I would love to see more information about how the statistics were gathered. How would using Firefox, Opera or Skyfire impact this? Does this really only mean that the majority of Android users don't use their built in browser when using the web? I know I frequently use either Firefox or Skyfire, though I've started to use the built in browser with ICS more. Comparatively, my impression at least is that the vast majority of users on iPhone/iPad use Safari.
In a family though it makes sense. My spouse got me a Galaxy Nexus for Christmas and her cousin (like 8) got his first cellphone from his parents for Christmas.
Right, but if I hadn't been to that version of that page before and something I hadn't loaded before tried to run I would STILL get a UAC prompt because that data file isnt hashed.
The entire data file doesn't have to have been run, just authorized. If it is unaltered, it could have run the last time when the file was run and the damage would be done. That said, one thing I realize you would give up is that once compromised by a legit app, there would need to be a mechanism checking entry points to make sure a new hashed exe isn't written and loaded directly in the future.
I'll take a look for the posts you mentioned. Most of my reading was pre Vista.
A data file can't do anything without being loaded in to memory to be executed on. As long as you are hashing everything loaded in (including files) then you should be ok against data files. This would limit the practicality in terms of things that have to work with data files, but would work great for certain tools and anything being used with common files. There is also the fact that if the app is known to behave well, then in many cases, any data file that is user requested is going to be irrelevant and automatically opened files should have existing hashes after the first few runs. If the data file is user loaded, then pre-authorized or not, it would still be a problem (the one exploit scenario would be if someone could programatically call the authorized executable passing in a file to open, so that could be a flaw).
I disagree with what the purpose of UAC was. As I recall, the stated purpose for UAC was to prevent malware from being able to get elevated privileges without the user having to authorize it. It was supposed to be a means of protecting the user from unauthorized software doing bad things. It ended up having the side effect of making developers try to avoid doing things they didn't need to, but I never got the impression that that was MS' intent in the implementation, at least not from any of the material they were distributing to partners when they were implementing it with Vista. If you have some documentation that suggests otherwise though, I think it would be an interesting read. I don't disagree that it was an effect, I just wasn't under the impression it was even an intended one, at least not the primary intention.
I think maybe you aren't fully understanding what I am suggesting. I will attempt to clarify on a point by point basis.
1) You don't try to hash the files directly, you hash on entry in to memory. It would probably look something like this. When an app first launches and needs elevation, the UAC prompt is given. When the user approves and specified to authorize for future use, it would load in to protected memory space and hash on what is loaded in to the elevated execution. After that, it would hash anything that was loaded in to memory or that was written out from memory in the elevated state, effectively tracking the authorized activities. On future runs, if anything tried to be loaded that didn't have a hash on file, the UAC prompt would be given. This might be difficult or even impossible to do for a native app, but should be reasonably easy to do with .Net apps at least.
2) This could be addressed with a maximum level of security that the persisted authorization would give. I know my main reason for wanting to be able to do pre-authorizations is that I have several monitoring and power user tools that I use which require administrative access to do their job fully. I have these set to run on start up since I use them all the time and it is frustrating to have to repeatedly click the UAC approval every time. Situations like this are what a feature like this would be perfect for.
3) There is possibly some truth to not wanting to give an average user access to this kind of functionality, but you also have to consider that the average user typically just clicks yes anyway, particularly if it shows up a lot. If you can reduce how often it shows up and also highlight if an elevated process has changed since last run, then it could make much more effective warning when something appears to be amok. As for your claim that I don't understand it, I don't know why you feel that way. Perhaps you simply didn't understand the full concept I was presenting and how it could work. I'm not saying it would work in every situation, but even if it could work in some, it would be helpful.
Make the command line parameters used for calling part of the hash then, perhaps part of the salt of it. My argument is simply that if you can be reasonably certain that the activity being performed is the same (exactly) as an action done in the past that was permitted, then it is likely still permitted (if the user choose to say they wanted that action to be permitted in the future.) If any part of the process is different or has not been previously authorized for future privileged access then the prompt should go again. The only vulnerability I can think of would be if the hash itself was compromised with the same length file as the previous (which is theoretically doable for some hashes, but not easy).
Perhaps I misunderstood your original post then. You mentioned that a hash of the executable wouldn't help because it opens some dlls or trusted data files, but for those files to be an issue, they must be able to be modified without elevated privileges which would mean that you are compromised as soon as you legitimatly launch the app the next time. In fact, if you were to store hashes of the files, it would offer additional protection as such tampering would be detected and a prompt would be given. If you know an app is pre-authorized and it prompts for authorization without having been modified, then you know something else modified it and the executable may not be safe.