3 ms·

Yes? In a system based on permissions (which is basically what a capability system is) somehow applications need to gain those permissions - so it makes sense

Yes? In a system based on permissions (which is basically what a capability system is) somehow applications need to gain those permissions - so it makes sense that an email client will need to request them. Otherwise how is it going to work if it cannot access the internet, the address book or any other functionality it might need? BTW the ILOVEYOU virus example is what the linked page brought up, not me. They call it "Love Bug" but that is just another name for the same virus: https://en.wikipedia.org/wiki/ILOVEYOU https://en.wikipedia.org/wiki/ILOVEYOU

bryanrasmussen 5y ago
yeah I'm old enough to be familiar with these things - is there some reason that you seem to think I'm in my early twenties? >In a system based on permissions (which is basically what a capability system is) somehow applications need to gain those permissions - so it makes sense that an email client will need to request them. Otherwise how is it going to work if it cannot access the internet, the address book or any other functionality it might need? first of all, most capability based security assumes applications have the permissions natural for them to achieve their task, thus an email client would have access to the address book. It would have access to read previous emails received, it would have access to get latest emails and send emails and display the emails. It might have permission to play a beep tone when email arrives. It would have all the normal common permissions required to be an email client. second of all, the access for the address book was requested by an attachment that was opened. Not the email client. To quote the first link: "In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. " To reiterate, it is not the email client that needs to ask every time it wants access to the address book, it is any executable opened from it. third of all, you have still not explained why opening an attachment would need those particular permissions. The linked article uses the virus specifically because something opened by an email client should not need those permissions! I mean I guess, since you said 'yes?' to my earlier question as to whether your argument was that those capabilities should be allowed because it was the kind of thing a virus asked for that is really your argument!?! Most people who talk about email security talk about what an awful application outlook is/was because of its bundling of the browser in to render html opening up all sorts of security holes but you seem to think that an email client (here I drop back to talking about the client instead of an attached executable) should be able to post to random websites data from the users address book based on instructions received in an email? I've never actually seen an email client that needed to do that? Why do you think that it needs to do that? I'm going in circles here but - because a famous virus needed to do it? Really? Fourth of all, your earlier example of someone messing up their system by installing Steam when they shouldn't is probably not the same as giving the Love Bug access it shouldn't have, but even if it were, yes people can do stupid things, your argument seems to be that any system that tries to help people stop before they do the stupid things will be doomed to failure instead of the common belief that some people will be stopped in their stupidity and caused to reconsider. It seems frankly weird because the only end to your argument that makes any sense would be no security whatsoever, because people will try to do stupid things thinking that the stupid thing they are attempting to do will somehow give them what they want.
- badsectoracula 5y ago
  > yeah I'm old enough to be familiar with these things - is there some reason that you seem to think I'm in my early twenties? No, i don't think that. Why you'd think that? If it was due to me writing about the ILOVEYOU virus, i wrote it because from your reply i got the impression that you thought the "Love Bug" virus (mentioned in the article) would be something different than the ILOVEYOU virus. I don't think age has anything to do with that though. > first of all, most capability based security assumes applications have the permissions natural for them to achieve their task [...] It would have all the normal common permissions required to be an email client. Yes, i agree with that and understand it, but... > second of all, the access for the address book was requested by an attachment that was opened. [...] To reiterate, it is not the email client that needs to ask every time it wants access to the address book, it is any executable opened from it. [...] you have still not explained why opening an attachment would need those particular permissions. ...the issue wasn't that the ILOVEYOU virus was an attachment, it was just a VBS script that was executable like any other executable could be - it could have been an EXE file instead and it'd be able to do the same things as the VBS script. To make it clear, an attachment would not need those particular permissions, but in the case of the ILOVEYOU virus it wasn't its status as an attachment that was the problem. The main issue, as far as Outlook Express was concerned, was that Outlook Express didn't provide any means to help users avoid these issues (which BTW is not the same as protecting them from the issues - one case empowers the users, the other treats them as powerless). And of course Windows made the issue worse with hiding filename extensions. As an example, nowadays Thunderbird provides pretty much the same features that Outlook Express had, including displaying of HTML content and even allowing access to the address book (instead of using some API you can use SQLite3 - but that is available in pretty much every language out there and the data is still just plain text). However you can switch off the HTML display or use a simplified one, have images not be downloaded by default to protect from remote attacks and tracking and it displays prominent warnings whenever it detects you are trying to launch an executable (this isn't ideal since, as i wrote in a previous message, many users will ignore the message, but it is still better than -say- Gmail disallowing executables completely). > I mean I guess, since you said 'yes?' And again to be clear, i wrote "yes" to that the email client would need those permissions (since that is what you wrote). The email client needs to be able to access the internet to function. But the attachment is not part of the email client, it is just a file that in the case of the ILOVEYOU virus, it happened to be an executable. In a permission or capability-based system that executable would need its own set of permissions that are independent of the email client. Which goes back to what i wrote initially: those permissions will need to somehow be acquired and the most logical way - and what, e.g., mobile phones do nowadays, since that is the most widely available form of permissions-based OSes - is to ask the user. But as the link i gave shows, most users do not pay attention to these requests - especially if they happen frequently - and just accept whatever is presented to them because what they have in mind isn't the requests and permissions to give, but performing the task the application would be for. The Linus Tech Tips video was a recent example of this of a user blindly accepting through every request and conformation presented him in the pursuit of the goal to do the task he had in mind - he wasn't interested in whatever the system was asking, he was interested in installing Steam. > It seems frankly weird because the only end to your argument that makes any sense would be no security whatsoever No, that is a defeatist attitude, my argument was really that the UX of the capability system that was proposed in the linked page about capability systems was a usability nightmare because it flies in the face of how users actually behave when faced with them. They do not solve the issues, at best they just make developers feel like they're doing something good, at worst they work as a way for developers to pass the blame from themselves to the users for ignoring the warnings. Either way the user is not "saved". There must be a better way that doesn't also remove any functionality from the system, but i don't really know what that would be. I'm certain though that a system that bombards users with confirmation dialogs aren't it since we have a ton of evidence that these do not work.

bryanrasmussen 5y ago

yeah I'm old enough to be familiar with these things - is there some reason that you seem to think I'm in my early twenties? >In a system based on permissions (which is basically what a capability system is) somehow applications need to gain those permissions - so it makes sense that an email client will need to request them. Otherwise how is it going to work if it cannot access the internet, the address book or any other functionality it might need? first of all, most capability based security assumes applications have the permissions natural for them to achieve their task, thus an email client would have access to the address book. It would have access to read previous emails received, it would have access to get latest emails and send emails and display the emails. It might have permission to play a beep tone when email arrives. It would have all the normal common permissions required to be an email client. second of all, the access for the address book was requested by an attachment that was opened. Not the email client. To quote the first link: "In either case, each time an executable program in your email executed, each time it needed a capability, you the user would be asked whether to grant that capability or not. " To reiterate, it is not the email client that needs to ask every time it wants access to the address book, it is any executable opened from it. third of all, you have still not explained why opening an attachment would need those particular permissions. The linked article uses the virus specifically because something opened by an email client should not need those permissions! I mean I guess, since you said 'yes?' to my earlier question as to whether your argument was that those capabilities should be allowed because it was the kind of thing a virus asked for that is really your argument!?! Most people who talk about email security talk about what an awful application outlook is/was because of its bundling of the browser in to render html opening up all sorts of security holes but you seem to think that an email client (here I drop back to talking about the client instead of an attached executable) should be able to post to random websites data from the users address book based on instructions received in an email? I've never actually seen an email client that needed to do that? Why do you think that it needs to do that? I'm going in circles here but - because a famous virus needed to do it? Really? Fourth of all, your earlier example of someone messing up their system by installing Steam when they shouldn't is probably not the same as giving the Love Bug access it shouldn't have, but even if it were, yes people can do stupid things, your argument seems to be that any system that tries to help people stop before they do the stupid things will be doomed to failure instead of the common belief that some people will be stopped in their stupidity and caused to reconsider. It seems frankly weird because the only end to your argument that makes any sense would be no security whatsoever, because people will try to do stupid things thinking that the stupid thing they are attempting to do will somehow give them what they want.

badsectoracula 5y ago
> yeah I'm old enough to be familiar with these things - is there some reason that you seem to think I'm in my early twenties? No, i don't think that. Why you'd think that? If it was due to me writing about the ILOVEYOU virus, i wrote it because from your reply i got the impression that you thought the "Love Bug" virus (mentioned in the article) would be something different than the ILOVEYOU virus. I don't think age has anything to do with that though. > first of all, most capability based security assumes applications have the permissions natural for them to achieve their task [...] It would have all the normal common permissions required to be an email client. Yes, i agree with that and understand it, but... > second of all, the access for the address book was requested by an attachment that was opened. [...] To reiterate, it is not the email client that needs to ask every time it wants access to the address book, it is any executable opened from it. [...] you have still not explained why opening an attachment would need those particular permissions. ...the issue wasn't that the ILOVEYOU virus was an attachment, it was just a VBS script that was executable like any other executable could be - it could have been an EXE file instead and it'd be able to do the same things as the VBS script. To make it clear, an attachment would not need those particular permissions, but in the case of the ILOVEYOU virus it wasn't its status as an attachment that was the problem. The main issue, as far as Outlook Express was concerned, was that Outlook Express didn't provide any means to help users avoid these issues (which BTW is not the same as protecting them from the issues - one case empowers the users, the other treats them as powerless). And of course Windows made the issue worse with hiding filename extensions. As an example, nowadays Thunderbird provides pretty much the same features that Outlook Express had, including displaying of HTML content and even allowing access to the address book (instead of using some API you can use SQLite3 - but that is available in pretty much every language out there and the data is still just plain text). However you can switch off the HTML display or use a simplified one, have images not be downloaded by default to protect from remote attacks and tracking and it displays prominent warnings whenever it detects you are trying to launch an executable (this isn't ideal since, as i wrote in a previous message, many users will ignore the message, but it is still better than -say- Gmail disallowing executables completely). > I mean I guess, since you said 'yes?' And again to be clear, i wrote "yes" to that the email client would need those permissions (since that is what you wrote). The email client needs to be able to access the internet to function. But the attachment is not part of the email client, it is just a file that in the case of the ILOVEYOU virus, it happened to be an executable. In a permission or capability-based system that executable would need its own set of permissions that are independent of the email client. Which goes back to what i wrote initially: those permissions will need to somehow be acquired and the most logical way - and what, e.g., mobile phones do nowadays, since that is the most widely available form of permissions-based OSes - is to ask the user. But as the link i gave shows, most users do not pay attention to these requests - especially if they happen frequently - and just accept whatever is presented to them because what they have in mind isn't the requests and permissions to give, but performing the task the application would be for. The Linus Tech Tips video was a recent example of this of a user blindly accepting through every request and conformation presented him in the pursuit of the goal to do the task he had in mind - he wasn't interested in whatever the system was asking, he was interested in installing Steam. > It seems frankly weird because the only end to your argument that makes any sense would be no security whatsoever No, that is a defeatist attitude, my argument was really that the UX of the capability system that was proposed in the linked page about capability systems was a usability nightmare because it flies in the face of how users actually behave when faced with them. They do not solve the issues, at best they just make developers feel like they're doing something good, at worst they work as a way for developers to pass the blame from themselves to the users for ignoring the warnings. Either way the user is not "saved". There must be a better way that doesn't also remove any functionality from the system, but i don't really know what that would be. I'm certain though that a system that bombards users with confirmation dialogs aren't it since we have a ton of evidence that these do not work.