tcpcrypt seems really out there. I can't really figure out what good it does. I haven't used it, so I'm basing all of this on the page you linked.
1) There is no apparent way to determine if your connection is being encrypted. Yeah, there's probably a log file somewhere--that's not really useful, though. I'm not going to change my behavior without knowing if there is encryption.
2) They really seem to downplay MITM on the page. They mention one particular attack--denying tcpcrypt to force the session to be a normal TCP session. What about a MITM acting as a proxy similarly to sslstrip? Now both sides think that they're using tcpcrypt, but there's someone listening in.
3) Somehow, the author thinks that authentication helps, but doesn't explain how. Does tcpcrypt have to share a credentials database with the application? Or does the author think that the fact that you must still log in protects you? This just doesn't make sense from the provided information.
E.g., the scripting issues for doing things in the wrong order, are very much hardware-independent. "All combinations" there just means: you just need to test all possible ways to finish a quest. I don't think it's that unreasonable to expect that to be tested.
Except that the set of all inputs might as well be infinite. What about completing the quest with a particular odd item in your inventory? With a particular odd set of items? I've seen bugs in other games where holding a particular item while talking to an NPC breaks completing a quest.
Edge cases are typically fairly well-known and ought to be easy to test, such as completing a quest with a full inventory or while in a burdened state. But "all possible ways" to complete a quest must assume every possible input, which is practically impossible.
In fact, you'd need to worry about the order in which you complete the quests (definitely for side quests, but also for main quests if it's possible to jump ahead like it was in Fallout 3.) Even if you don't care about the state of your character when you complete the quest (e.g. skills, inventory) you're talking about a huge number of permutations.
There are bugs and then there are bugs. When Fallout 3 first came out, some players (on console) couldn't get past the initial tutorial/character creation screen.
In iOS, an application always has access to its own keychain items and does not have access to any other application’s items. The system generates its own password for the keychain, and stores the key on the device in such a way that it is not accessible to any application. When a user backs up iPhone data, the keychain data is backed up but the secrets in the keychain remain encrypted in the backup. The keychain password is not included in the backup. Therefore, passwords and other secrets stored in the keychain on the iPhone cannot be used by someone who gains access to an iPhone backup. For this reason, it is important to use the keychain on iPhone to store passwords and other data (such as cookies) that can be used to log into secure web sites.
I'm not sure where the password is stored. I'd be curious to know if it is on the filesystem (and thus accessible when jailbroken) or if it is perhaps stored in silicon somewhere, and whether this password survives system restores.
The difference is where you watch it. HuluPlus has apps for various platforms such as the PS3 and iPad. Hulu does not. Therefore you can't watch a Hulu-only show on those devices--only HuluPlus shows.
The "no liability" disclaimers from developers is BS. If you provide me a banking app, and through the normal, intended use of that app, my account is compromised, then you should be liable.
The iPhone encrypts the storage so that it can wipe by merely overwriting the key instead of the whole storage. It's not really encryption for most intents.
Good point. I'd say that for a given instance of providing it, you'd be right. Most filesharing is on a broad, broad scale, which means that the chances of giving it to someone who is going to "shoot someone with it" is much higher. If I just dumped a bunch of m-16s with child locks in a public square and walked away, I'd consider that immoral. If I gave one to someone I knew, and whom I believed would be responsible, that's a different matter.
If all Slashdotters shared identical opinions, we probably wouldn't have very many comments.
Regarding GPL, the GPL is really an abuse of copyright aimed at "patching" a broken system. GPL advocates don't see why I can buy a table or chair and refinish it, reupholster it, cut it in half and add a leaf, etc. but you can't remix/modify legally acquired software.
"okay" is not a very precise term. "Morally right" or "morally wrong" might be better.
I think that downloading copyrighted material is largely amoral. It might be immoral if you would have paid for it had the ability to download it not been available.
I think that taking someone else's work and providing it to someone else falls on the immoral side most of the time--you can't know whether or not that person would have purchased the work if you had not given it to them.
I think that selling someone else's work is pretty much always immoral. Exceptions might be abandoned works.
I guess this might solve the chicken/egg problem of improving HTML5 adoption. Unfortunately, it means that we're now relying on a proprietary service (with potential legal issues) instead of open standards or proprietary plugins. This will not likely reduce Flash usage by developers much, since they can produce flash videos and still get everyone to see them. And if the service goes down, or Hulu sues the pants off of Skyfire, we're stuck without those videos.
It would be better for Flash to just completely die off. What we want is for developers to start moving to HTML5, not for shims to allow the use of Flash to continue in the background.
Honestly, I'd love it if theaters took people's phones before going in. I can't stand it when all of those tiny screens in front of me start lighting up.
In most browsers, with most configurations, the link shows bright blue. I saw the post, saw the bright blue "Bullshit", and decided it wasn't worth reading the rest unless he decided to be more civil.
Yeah, and then I mentioned a different web server. Maybe I don't want to run ancient software.
And to avoid that internet-age-old ad-hominem 'troll' attack, I realize that Apache 1.3 was only recently EOL'd by Apache, but development on it effectively ceased long ago. Which is why I referenced a more modern web server, though you conveniently declined to quote that portion of my post.
Re:OSNews? Thom Holwerda? Seriously?
on
OpenBSD 4.8 Released
·
· Score: 0, Offtopic
You lost me at the highlighted "bullshit." If you want to have an intelligent conversation, try not being rude.
Re:OSNews? Thom Holwerda? Seriously?
on
OpenBSD 4.8 Released
·
· Score: 2, Interesting
Insightful? Really?
The point of the article is that while the base system may indeed be very secure, it is practically useless. When needing to perform real world functions, the ironclad security of the base install is not all that useful. It's true that providing a good base on which to build your platform is important, however it's not nearly as important as one might think.
For example, if you need to build a web server, you might pick OpenBSD because of its "secure-by-default" mantra. But what does that really buy you? You still need to run web server software, which is going to be the vector for any attack. Is lighttpd any more secure on OpenBSD than on Linux? No. All you get with OpenBSD is that it's far less likely that there will be a local security exploit to chain with the lighttpd remote exploit. But with SELinux, you can get an even higher level of security. With SELinux, you need not only a local privilege escalation, but a hole in SELinux as well.
I would argue that OpenBSD may be secure by design, but SELinux is, in practice, more secure.
I would be absolutely ecstatic if OpenBSD implemented something more like SELinux in terms of privilege separation.
Yup. My old WinMo phone and my Android phone both have to be on for the alarm to work. My old Motorola candy-bar phone (I don't remember the model) was the same.
Less reliable? Most alarm clock have a place for a battery, which solves the issue of unstable power grids. I've never had an alarm clock crash overnight, or be so lagged with crap programs running that the alarm program either didn't run or started late. I've never had an alarm clock lock up.
I use my phone as an alarm for convenience, but I recognize that it's less reliable. I've had all of the above happen to me with various phones.
I considered using Linux in a VM for most of my browsing, but I found that e.g. fullscreen video (Flash, html5, etc.) performs terribly. Do you not have this problem?
If there were even the inkling that the groups pushing this shit (in any company) were going to offer an easy means of disabling this for power users, I don't think there would be complaints. But they don't. And they want to push it far and wide, and make getting out from under it a pain in the ass.
They said that they would let you disable the Mac lockdown in the exact same paragraph where they described the Mac lockdown. Obviously, you didn't bother reading it.
I'm just going off of the definition of undefined behavior from the standard:
1.3.13 undefined behavior [defns.undefined] behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [ Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a trans- lation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefinedbehavior;theyarerequiredtobediagnosed. —endnote]
Emphasis is mine.
Unless you weren't using the standard's definition of "undefined behavior", in which case please let me know, but feel free to otherwise ignore my question.
tcpcrypt seems really out there. I can't really figure out what good it does. I haven't used it, so I'm basing all of this on the page you linked.
1) There is no apparent way to determine if your connection is being encrypted. Yeah, there's probably a log file somewhere--that's not really useful, though. I'm not going to change my behavior without knowing if there is encryption.
2) They really seem to downplay MITM on the page. They mention one particular attack--denying tcpcrypt to force the session to be a normal TCP session. What about a MITM acting as a proxy similarly to sslstrip? Now both sides think that they're using tcpcrypt, but there's someone listening in.
3) Somehow, the author thinks that authentication helps, but doesn't explain how. Does tcpcrypt have to share a credentials database with the application? Or does the author think that the fact that you must still log in protects you? This just doesn't make sense from the provided information.
E.g., the scripting issues for doing things in the wrong order, are very much hardware-independent. "All combinations" there just means: you just need to test all possible ways to finish a quest. I don't think it's that unreasonable to expect that to be tested.
Except that the set of all inputs might as well be infinite. What about completing the quest with a particular odd item in your inventory? With a particular odd set of items? I've seen bugs in other games where holding a particular item while talking to an NPC breaks completing a quest.
Edge cases are typically fairly well-known and ought to be easy to test, such as completing a quest with a full inventory or while in a burdened state. But "all possible ways" to complete a quest must assume every possible input, which is practically impossible.
In fact, you'd need to worry about the order in which you complete the quests (definitely for side quests, but also for main quests if it's possible to jump ahead like it was in Fallout 3.) Even if you don't care about the state of your character when you complete the quest (e.g. skills, inventory) you're talking about a huge number of permutations.
There are bugs and then there are bugs. When Fallout 3 first came out, some players (on console) couldn't get past the initial tutorial/character creation screen.
The PIN seems to be irrelevant, actually.
In iOS, an application always has access to its own keychain items and does not have access to any other application’s items. The system generates its own password for the keychain, and stores the key on the device in such a way that it is not accessible to any application. When a user backs up iPhone data, the keychain data is backed up but the secrets in the keychain remain encrypted in the backup. The keychain password is not included in the backup. Therefore, passwords and other secrets stored in the keychain on the iPhone cannot be used by someone who gains access to an iPhone backup. For this reason, it is important to use the keychain on iPhone to store passwords and other data (such as cookies) that can be used to log into secure web sites.
-- http://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html#//apple_ref/doc/uid/TP30000897-CH204-TP9
I'm not sure where the password is stored. I'd be curious to know if it is on the filesystem (and thus accessible when jailbroken) or if it is perhaps stored in silicon somewhere, and whether this password survives system restores.
The difference is where you watch it. HuluPlus has apps for various platforms such as the PS3 and iPad. Hulu does not. Therefore you can't watch a Hulu-only show on those devices--only HuluPlus shows.
There may be some overlap, but it is not total.
The "no liability" disclaimers from developers is BS. If you provide me a banking app, and through the normal, intended use of that app, my account is compromised, then you should be liable.
The iPhone encrypts the storage so that it can wipe by merely overwriting the key instead of the whole storage. It's not really encryption for most intents.
Good point. I'd say that for a given instance of providing it, you'd be right. Most filesharing is on a broad, broad scale, which means that the chances of giving it to someone who is going to "shoot someone with it" is much higher. If I just dumped a bunch of m-16s with child locks in a public square and walked away, I'd consider that immoral. If I gave one to someone I knew, and whom I believed would be responsible, that's a different matter.
If all Slashdotters shared identical opinions, we probably wouldn't have very many comments.
Regarding GPL, the GPL is really an abuse of copyright aimed at "patching" a broken system. GPL advocates don't see why I can buy a table or chair and refinish it, reupholster it, cut it in half and add a leaf, etc. but you can't remix/modify legally acquired software.
"okay" is not a very precise term. "Morally right" or "morally wrong" might be better.
I think that downloading copyrighted material is largely amoral. It might be immoral if you would have paid for it had the ability to download it not been available.
I think that taking someone else's work and providing it to someone else falls on the immoral side most of the time--you can't know whether or not that person would have purchased the work if you had not given it to them.
I think that selling someone else's work is pretty much always immoral. Exceptions might be abandoned works.
In my opinion, statuatory awards shouldn't be covered under this anyway. Statuatory awards don't reflect the actual injury at all.
Kinda.
I guess this might solve the chicken/egg problem of improving HTML5 adoption. Unfortunately, it means that we're now relying on a proprietary service (with potential legal issues) instead of open standards or proprietary plugins. This will not likely reduce Flash usage by developers much, since they can produce flash videos and still get everyone to see them. And if the service goes down, or Hulu sues the pants off of Skyfire, we're stuck without those videos.
It would be better for Flash to just completely die off. What we want is for developers to start moving to HTML5, not for shims to allow the use of Flash to continue in the background.
Honestly, I'd love it if theaters took people's phones before going in. I can't stand it when all of those tiny screens in front of me start lighting up.
In most browsers, with most configurations, the link shows bright blue. I saw the post, saw the bright blue "Bullshit", and decided it wasn't worth reading the rest unless he decided to be more civil.
Yeah, and then I mentioned a different web server. Maybe I don't want to run ancient software.
And to avoid that internet-age-old ad-hominem 'troll' attack, I realize that Apache 1.3 was only recently EOL'd by Apache, but development on it effectively ceased long ago. Which is why I referenced a more modern web server, though you conveniently declined to quote that portion of my post.
You lost me at the highlighted "bullshit." If you want to have an intelligent conversation, try not being rude.
Insightful? Really?
The point of the article is that while the base system may indeed be very secure, it is practically useless. When needing to perform real world functions, the ironclad security of the base install is not all that useful. It's true that providing a good base on which to build your platform is important, however it's not nearly as important as one might think.
For example, if you need to build a web server, you might pick OpenBSD because of its "secure-by-default" mantra. But what does that really buy you? You still need to run web server software, which is going to be the vector for any attack. Is lighttpd any more secure on OpenBSD than on Linux? No. All you get with OpenBSD is that it's far less likely that there will be a local security exploit to chain with the lighttpd remote exploit. But with SELinux, you can get an even higher level of security. With SELinux, you need not only a local privilege escalation, but a hole in SELinux as well.
I would argue that OpenBSD may be secure by design, but SELinux is, in practice, more secure.
I would be absolutely ecstatic if OpenBSD implemented something more like SELinux in terms of privilege separation.
Yup. My old WinMo phone and my Android phone both have to be on for the alarm to work. My old Motorola candy-bar phone (I don't remember the model) was the same.
Less reliable? Most alarm clock have a place for a battery, which solves the issue of unstable power grids. I've never had an alarm clock crash overnight, or be so lagged with crap programs running that the alarm program either didn't run or started late. I've never had an alarm clock lock up.
I use my phone as an alarm for convenience, but I recognize that it's less reliable. I've had all of the above happen to me with various phones.
The problem is not that they make it easy. The problem is that they intentionally make it hard to tinker with.
I actually like d2. I hate loading new pages for comments below my threshold. I just wish d2 worked better on iOS.
I considered using Linux in a VM for most of my browsing, but I found that e.g. fullscreen video (Flash, html5, etc.) performs terribly. Do you not have this problem?
If there were even the inkling that the groups pushing this shit (in any company) were going to offer an easy means of disabling this for power users, I don't think there would be complaints. But they don't. And they want to push it far and wide, and make getting out from under it a pain in the ass.
They said that they would let you disable the Mac lockdown in the exact same paragraph where they described the Mac lockdown. Obviously, you didn't bother reading it.
Yeah, if that is racism, to whom do I bitch about not getting BBC streaming in the states?
I'm just going off of the definition of undefined behavior from the standard:
1.3.13 undefined behavior [defns.undefined]
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [ Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a trans- lation or execution (with the issuance of a diagnostic message). Many erroneous program constructs do not engender undefinedbehavior;theyarerequiredtobediagnosed. —endnote]
Emphasis is mine.
Unless you weren't using the standard's definition of "undefined behavior", in which case please let me know, but feel free to otherwise ignore my question.