Re: Google SoC, To-Do
Dnia niedziela, 18 marca 2007, [EMAIL PROTECTED] napisał: I have already posted an application for Footer. Maybe as sidework I will write To-Do app. I definetly need one on modile, and quite complicated one. OpenedHand created application named 'Tasks' which would be trivial to port to OpenMoko framework. Afaik todos will be part of Openmoko-dates. -- JID: hrw-jabber.org OpenEmbedded developer/consultant there are actually only 10 web sites out there, all the others are rearranged copies ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joel Newkirk wrote: Tobias Gruetzmacher wrote: What I'm proposing is a user-friendly encryption scheme of the data the user stores in his phone, so any illegitimate user will not be able to get personal data about the owner of the phone. I'd like a good gestural interface for authentication - a passphrase or password would be a pain with a mini virtual keyboard, a pincode would remain a pain in many situations, a personalized fingertip doodle would be great. Present a virtual keypad but allow a finger-drawn character or shape to authenticate. If an abstract module like PAM is used for this, the user can customize the authentication method she wants to use. With regards to encryption - it'd be great if microSD cards can contain dm-crypt'ed partitions. It's probably rather trivial to add this. -Sven ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Crossroads
Dear Community, A big thanks again for all your feedback! We're meeting with vendors this week and are optimistic about our chances to find a WiFi module. We'll keep you all posted and announce the winner of the free phone once we find the right solution. As for the UI / Application developer work request, we're still processing these emails. Please bare with us as we are just overwhelmed with tasks trying to get the devices built this month. -Sean ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
wireless programming
Sorry for the mass mail, but I want to know if anyone has any experience with wireless ad hoc network programming. Specifically dealing with peer discovery. I would appreciate any help and can be contacted through my email: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Moin, Am Mon, 19 Mar 2007 01:16:30 +0100 schrieb Alexander E Genaud: Secondly, many banks and corporations require authentication with the assistance of a token. Some devices display a seemingly random number every minute or so, while others accept pin codes and challenges. It might be difficult for a third party (Openmoko) to interface with existing systems (do VeriSign, ActivCard/Identy and the like make public keys actually, uh, public?). I just stumbled on http://www.openauthentication.org which seems to provide an open interface for that sort of thing. I didn't read it any closer but it might be worth looking into. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko at Chaosradio
Esra Kummer wrote: There is an interview with Harald Welte (Senior Software Archtitect System Level of the project)about the OpenMoko project. Length 01:16:36h. I guess an URL would have been nice ;-) http://chaosradio.ccc.de/cre042.html Oh dear I am sorry. It's always the same with writing emails... I forget all the time the file or link... thx for posting it Rolf ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Hi, Am Mon, 19 Mar 2007 12:28:28 +0100 schrieb Sven Neuhaus: With regards to encryption - it'd be great if microSD cards can contain dm-crypt'ed partitions. It's probably rather trivial to add this. Partitions are a major usability nightmare IMHO. That is the reason my proposal focused on encfs/ecryptfs, which both are layered encryption file systems. This removes the requirement to set a fixed size for the encrypted space and makes it easy to use standard tools to backup the encrypted data. Greetings, Tobi -- GPG-Key 0xE2BEA341 - signed/encrypted mail preferred My, oh so small, homepage: http://portfolio16.de/ http://www.fli4l.de/ - ISDN- DSL-Router on one disk! Registered FLI4L-User #0003 ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Me too. I want to use the moko to control a media center PC that is connected to my stereo, for queuing up audio files and etc. My PC uses a video projector for the monitor and turning on the projector is too much trouble just for queuing up audio. Leaving the projector on uses up the bulb life too. I wonder if one of the linux based media center apps like mythTV would work for this? A custom remote control app for the moko would be best, but a web browser interface would be fine too. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tobias Gruetzmacher wrote: Hi, Am Mon, 19 Mar 2007 12:28:28 +0100 schrieb Sven Neuhaus: With regards to encryption - it'd be great if microSD cards can contain dm-crypt'ed partitions. It's probably rather trivial to add this. Partitions are a major usability nightmare IMHO. That is the reason my proposal focused on encfs/ecryptfs, which both are layered encryption file systems. This removes the requirement to set a fixed size for the encrypted space and makes it easy to use standard tools to backup the encrypted data. Greetings, Tobi Just wanted to throw my $.02 into the mix. I think the most important aspect of this is ease of use...KISS. Some of the ideas floating around are over the top. It might give you warm fuzzies to have some super cool encryption scheme, but it will be completely pointless if you make it so difficult to use that (normal) people don't use it. There is a big difference between what is needed for keeping nuclear launch codes and your shopping list secure. Since it is much more likely that you will be storing your shopping list rather than top-secret documents, lets focus on encryption schemes that are more target for that use. Also, *most* times that a phone is lost/stolen people are just going to want to wipe it then sell on eBay, not hook up a debug board and do a memory dump. Seriously, where are you at that crooks are THAT tech savvy??? Please let me know so I can stay far far away. Now to contribute something productive, rather than just complain on the list. Here are two ideas that if used together be simple and effective. 1) I do like the gesture based approach as that is something that can be easily input using one hand (remember, KISS). However, that may not go over as well for a non-phone interface. So, having an intermediate layer that transform gestures to a key-phrase would be a great idea. Then you can have a preference to either input your password/key-phrase directly OR you can launch the gesture analyzer and that will handle the inputting of your password/key-phrase. 2) The sudo style of access could also be useful. Whenever private data (still not sure the best/most user friendly approach to determining what is and isn't) is accessed, you are required to put in a password (via method above) and it will last for a pre-determined amount of time. Just the combination of those two ideas would probably suffice for +90% of users needs. Then, if someone was actually carrying nuclear launch codes, then a secondary more robust implementation could either replace or supplement. But your grandmother would still be able to (hopefully) figure out that scheme. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
Thank u, The same idea made me think of a way to link open moko with real world ..'Can open moko make coffee'.. The interface could be either through usb or RF .. For the above mentioned ideas like connecting phone to external circuitries like microcontroller , i think it is a good idea to use usb... Anyway i am excited to see this idea implemented some way -Anil On 3/19/07, Richi Plana [EMAIL PROTECTED] wrote: On Mon, 2007-03-19 at 13:24 +0100, Cecil Westerhof wrote: 2007/3/19, Anil Franklin [EMAIL PROTECTED]: Can OpenMoko Make Coffee? - SoC Project Proposal -- The Coffee HOWTO ( http://tldp.org/HOWTO/Coffee.html ) begins by asserting that Linux DOES make Coffee, and it tastes good!; it then goes on to describe how you can control devices like say a coffee machine using the PC parallel port and some simple electronics. I think it is a nice idea. The only thing I wonder: is it usefull? A phone is something you normally take with you. I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Richi Plana ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
Ben Burdette wrote: I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Me too. I want to use the moko to control a media center PC that is connected to my stereo, for queuing up audio files and etc. My PC uses a video projector for the monitor and turning on the projector is too much trouble just for queuing up audio. Leaving the projector on uses up the bulb life too. I wonder if one of the linux based media center apps like mythTV would work for this? A custom remote control app for the moko would be best, but a web browser interface would be fine too. MythTV can be adapted to just about anything that you can think of. I'll be the first to say that it is more difficult to get setup initially (compared to a Windows Media Center), but once you've got it up and running then you've just begun to scratch the surface of what all it can do. MythTV does have a web-interface. Depending on what all you are wanting to do, it is possible that what you are wanting is already available, and the Neo's built-in browser could probably handle all of the controls. If not, then both are open-sourced and you could throw something together to fit your needs. Hope that helps, Jonathon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
Ben Burdette wrote: I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Me too. I want to use the moko to control a media center PC that is connected to my stereo, for queuing up audio files and etc. My PC uses a video projector for the monitor and turning on the projector is too much trouble just for queuing up audio. Leaving the projector on uses up the bulb life too. I wonder if one of the linux based media center apps like mythTV would work for this? A custom remote control app for the moko would be best, but a web browser interface would be fine too. hmm, bluetooth at both ends. is there a way to send a custom protocol between bluetooth devices without the need for a maintained serial style connection? hmm, i wonder if mythtv already have support for bluetooth based remote control... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
kenneth marken wrote: Ben Burdette wrote: I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Me too. I want to use the moko to control a media center PC that is connected to my stereo, for queuing up audio files and etc. My PC uses a video projector for the monitor and turning on the projector is too much trouble just for queuing up audio. Leaving the projector on uses up the bulb life too. I wonder if one of the linux based media center apps like mythTV would work for this? A custom remote control app for the moko would be best, but a web browser interface would be fine too. hmm, bluetooth at both ends. is there a way to send a custom protocol between bluetooth devices without the need for a maintained serial style connection? hmm, i wonder if mythtv already have support for bluetooth based remote control... err, while it may be bad netiquette to reply to oneself, i found this over on the mythtv wiki: http://mythtv.org/wiki/index.php/Bluetooth_Remote_with_WM5_Smartphone i guess one should be able to use the same mythbox part, but write a different part for the neo... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Flash Player 9 on OpenMoko?
Sorry, I'm late to the party, but is anyone working with Adobe to get a build of Flash Player 9 for OpenMoko and/or ARM/Samsung's SoC chips? -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
I thought this service is already available in moko 'bluetooth services' ...Otherwise it has to be there... We have implemented the same idea for Nokia s60 (Symbian OS) phones using bluetooth... *There u could control the media playing on pc..from a distance.. *You can browse net from a python interface... *You can even control the pc through commands through your mobile.. *You can use ur mobile like a remote ... I think it could be easily done in moko too... On 3/20/07, Jonathon Suggs [EMAIL PROTECTED] wrote: Ben Burdette wrote: I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Me too. I want to use the moko to control a media center PC that is connected to my stereo, for queuing up audio files and etc. My PC uses a video projector for the monitor and turning on the projector is too much trouble just for queuing up audio. Leaving the projector on uses up the bulb life too. I wonder if one of the linux based media center apps like mythTV would work for this? A custom remote control app for the moko would be best, but a web browser interface would be fine too. MythTV can be adapted to just about anything that you can think of. I'll be the first to say that it is more difficult to get setup initially (compared to a Windows Media Center), but once you've got it up and running then you've just begun to scratch the surface of what all it can do. MythTV does have a web-interface. Depending on what all you are wanting to do, it is possible that what you are wanting is already available, and the Neo's built-in browser could probably handle all of the controls. If not, then both are open-sourced and you could throw something together to fit your needs. Hope that helps, Jonathon ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
- Original Message From: kenneth marken [EMAIL PROTECTED] To: community@lists.openmoko.org Sent: Monday, March 19, 2007 12:06:56 PM Subject: Re: Can OpenMoko Make Coffee? - SoC Project Proposal kenneth marken wrote: Ben Burdette wrote: I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Me too. I want to use the moko to control a media center PC that is connected to my stereo, for queuing up audio files and etc. My PC uses a video projector for the monitor and turning on the projector is too much trouble just for queuing up audio. Leaving the projector on uses up the bulb life too. I wonder if one of the linux based media center apps like mythTV would work for this? A custom remote control app for the moko would be best, but a web browser interface would be fine too. hmm, bluetooth at both ends. is there a way to send a custom protocol between bluetooth devices without the need for a maintained serial style connection? hmm, i wonder if mythtv already have support for bluetooth based remote control... plutohome (which uses mythTV) does this already IIRC. It also uses the bluetooth to track the user through the house. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
On Monday 19 March 2007 20:44:55 Ben Burdette wrote: A custom remote control app for the moko would be best, but a web browser interface would be fine too. IIRC there's a few Amarok scripts that expose a webinterface. Or you could look into Bemused. pgpFWOjuWX9n7.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
MythTV server is available..
Mythcontrol server implimentation using bluetooth : http://www.sourceforge.net/projects/mythcontrol ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flash Player 9 on OpenMoko?
As far as I know there is not even an adobe flashplayer for amd64 on linux .. why should there be one for ARM ? In addition the adobe flashplayer is not free .. maybe we use swfdec or gnash .. of course they do not have the same funtionality but they will do the job :) martin ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
I noticed the other day that MythTV has an option to Enable Network Remote Control interface. Looks like this is just a port you can telnet to and pass commands. I intend to write a remote control app that would run on OpenMoko. Cause I think that would be awesome. Of course, it would only really be useful if the Neo has wifi... Hmm... Maybe I should create that project on openmoko.org. -Steven On 3/19/07, Ben Burdette [EMAIL PROTECTED] wrote: I think that the Neo1973 is both a phone and a portable handheld device. Using it as a remote control is one of the things I've personally been interested in this whole thing for. I'd like to think of the OpenMoko device as an extension of myself into the world of electronic devices. My own interface with the world ... until such time as we can get wetware to do brain-computer interfaces, ;). -- Me too. I want to use the moko to control a media center PC that is connected to my stereo, for queuing up audio files and etc. My PC uses a video projector for the monitor and turning on the projector is too much trouble just for queuing up audio. Leaving the projector on uses up the bulb life too. I wonder if one of the linux based media center apps like mythTV would work for this? A custom remote control app for the moko would be best, but a web browser interface would be fine too. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can OpenMoko Make Coffee? - SoC Project Proposal
You mean like this except with a coffee maker? http://xe.bz/aho/24/ No ;) Marty Date: Tue, 20 Mar 2007 00:30:09 +0530 From: Anil Franklin [EMAIL PROTECTED] Thank u, The same idea made me think of a way to link open moko with real world ..'Can open moko make coffee'.. The interface could be either through usb or RF .. For the above mentioned ideas like connecting phone to external circuitries like microcontroller , i think it is a good idea to use usb... Anyway i am excited to see this idea implemented some way -Anil ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flash Player 9 on OpenMoko?
Martin Raißle wrote: As far as I know there is not even an adobe flashplayer for amd64 on linux .. why should there be one for ARM ? In addition the adobe flashplayer is not free .. maybe we use swfdec or gnash .. of course they do not have the same funtionality but they will do the job :) And even if we were to consider using proprietary software on the device the license for Flash player does not allow you to use it on an embedded device: http://www.adobe.com/products/eulas/players/flash/ ... ... 3. Restrictions. 3.1 Web Player Prohibited Devices. You may not Use any Web Player on any non-PC device or with any embedded or device version of any operating system. For the avoidance of doubt, and by example only, you may not use a Web Player on any (a) mobile devices, set top boxes (STB), handhelds, phones, web pads, tablets and Tablet PCs that are not running Windows XP Tablet PC Edition, game consoles, TVs, DVD players, media centers (excluding Windows XP Media Center Edition and its successors), electronic billboards or other digital signage, internet appliances or other internet-connected devices, PDAs, medical devices, ATMs, telematic devices, gaming machines, home automation systems, kiosks, remote control devices, or any other consumer electronics device, (b) operator-based mobile, cable, satellite, or television systems or (c) other closed system devices. ... ... So if you want Flash use Gnash. Cheers//Frank ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 2007-03-19 at 22:57 +0100, Marcel de Jong wrote: From a user's standpoint: I do not think I'd like to enter a passphrase or any other measures just to open up my contacts list (which is after all a piece of personal data). Also for opening my calendar and such actions on the device, I'd prefer to have no passphrase. snip a de doo daa I think Marcel is probably stating what *most* people are going to want as well. Having the ability to encrypt data is a priority, but not having to use it should be a higher priority. One of the biggest mantra's I hear coming from the FOSS camp is choice and so keeping with the whole practice what you preach ideal, I think the level of encryption should be a user configurable preference. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Jonathon Suggs wrote: One of the biggest mantra's I hear coming from the FOSS camp is choice and so keeping with the whole practice what you preach ideal, I think the level of encryption should be a user configurable preference. I'd caveat that with comment that one of the biggest bugbears against the FOSS camp is usability so if this type of thing is going to be implemented then it should be a single system-wide option that gets handled away in the backend so that applications don't even need to know about it and that users don't have to pick and choose (or worse, select on a per-application basis) what data is encrypted. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Neo-use idea
If someone wants to repurpose the neo hardware, check out what the guys at http://www.environmental-studies.de/products/pet-tracking/pet-tracking.h tml are doing. They're sold out for now, but they might be worth talking to to see if they want to try and start from a base Neo and just add some custom software to. Random idea as I was browsing the web. --pj ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Jim McDonald writes: Jonathon Suggs wrote: One of the biggest mantra's I hear coming from the FOSS camp is choice and so keeping with the whole practice what you preach ideal, I think the level of encryption should be a user configurable preference. I'd caveat that with comment that one of the biggest bugbears against the FOSS camp is usability so if this type of thing is going to be implemented then it should be a single system-wide option that gets handled away in the backend so that applications don't even need to know about it and that users don't have to pick and choose (or worse, select on a per-application basis) what data is encrypted. We certainly want a global scheme -- but I think we do want a per-data-item granularity. I've certainly got things on my phone whose protection I don't care about (shopping lists) and other things that have legal implications (notes on how various students' class presentations went). I want to be able to choose save this encrypted vs. save this, and then when I access data I've encrypted I have to enter the password. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joe Pfeiffer wrote: [Encrypting data] We certainly want a global scheme -- but I think we do want a per-data-item granularity. I've certainly got things on my phone whose protection I don't care about (shopping lists) and other things that have legal implications (notes on how various students' class presentations went). I want to be able to choose save this encrypted vs. save this, and then when I access data I've encrypted I have to enter the password. Yep but on the flipside if you have some data that you want encrypted then encrypting all of it won't do any harm (perhaps a slightly slower response time, and assuming some sort of key caching going on the occasional entering of a decryption token, perhaps on unlock and 'phone startup?). Having to choose for each piece of data if it is encrypted or not, and having to handle that in every application individually, is a great example of where choice can be too much. I think that having a single system-wide setting and handling it appropriately (and far enough down the stack so that applications don't have to worry about it) would provide a simple and uniform approach to this problem without continually asking the user to decide which data is to be encrypted and which not. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Clare Johnstone wrote: On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare True, but that's just another choice to be made when storing the data plus of course you have filesystem folders, arbitrary categorisation through tags, automatic classification depending on the type of data etc. so there are lots of concepts that can be used, and each one is a potential set of confusion (I tagged the data as 'sensitive' but the system didn't encrypt it because I accidentally put it in the 'public' folder). I just think that this is a good example where having an all-or-nothing approach is preferable to fine-grained control, as the benefits are minimal compared to the complexity for development and day-to-day effort for end-users that have to use such a system. Cheers, Jim. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 19 Mar 2007 18:25, Jim McDonald wrote: Clare Johnstone wrote: On 3/20/07, Jim McDonald [EMAIL PROTECTED] wrote: continually asking the user to decide which data is to be encrypted and which not. There is the concept of folders which could be used :) clare True, but that's just another choice to be made when storing the data plus of course you have filesystem folders, arbitrary categorisation through tags, automatic classification depending on the type of data etc. so there are lots of concepts that can be used, and each one is a potential set of confusion (I tagged the data as 'sensitive' but the system didn't encrypt it because I accidentally put it in the 'public' folder). I just think that this is a good example where having an all-or-nothing approach is preferable to fine-grained control, as the benefits are minimal compared to the complexity for development and day-to-day effort for end-users that have to use such a system. Cheers, Jim. Ok.. Lets assume for a moment that there is an encryption / security engine.. And its hooked through dbus somehow.. Lets also assume there is a mechanism that handles all requests to save data from any application... Will just call it the save data mechanism.. (Grin)... So on the encryption / security engine it seems like there should be the ability to define user selectable levels of encryption / security.. Such as no encryption but password required.. Light encryption password required... Heavy encryption picture/gesture required (and maybe a certainty level for fuzzy matching like 90% /shrug).. or no password and no encryption.. Etc. Ok. There should be some kind of configuration for the save data mechanism which says select the published security levels (I.e. Those the user created in the security config) and then select which applications follow those rules.. So notes could be no security/no password or it could be 'ask me each time'... Calendar could be the same.. File browser could be heavy encryption with picture.. Etc.. Then each application does not need to know anything about the security levels at all. It just calls the save information api (whatever that is) and hands dbus the data to save. The save mechanism looks at the request and notes the application its coming from and then hands it off to the security engine to encrypt appropriately.. And then it hands it back at which point the save data mechanism can write it to the file system.. Reading is the same.. Except the read data mechanism looks at the application making the request and in the case of ask me data looks at the data to see if its encrypted/secured.. If so it tells the security mechanism which asks the user for the appropriate level of password information and then decrypts or authenticates the read action and the user gets to read the data. Combined with the sudo idea about a configurable amount of time for authorized idleness... And add to it the ability elevate permission levels.. So that once you have authorized to read highly sensitive information you can also just read password protected but not encrypted info.. And then I think it might meet everyones needs. By default no security is provided and none required.. Once configured it could handle almost any level of detail for encryption assuming someone wanted to go through the trouble of making it happen that way. And you could build new security mechanisms that plug into the architecture and allow for some people gesture authentication and for others hand writing codes or voice codes or numeric codes or anything. Um... Yeah.. Ok so that might be 10 cents worth. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom writes: Ok.. Lets assume for a moment that there is an encryption / security engine.. And its hooked through dbus somehow.. Lets also assume there is a mechanism that handles all requests to save data from any application... Will just call it the save data mechanism.. (Grin)... So on the encryption / security engine it seems like there should be the ability to define user selectable levels of encryption / security.. Such as no encryption but password required.. Light encryption password required... Heavy encryption picture/gesture required (and maybe a certainty level for fuzzy matching like 90% /shrug).. or no password and no encryption.. Etc. Ok. There should be some kind of configuration for the save data mechanism which says select the published security levels (I.e. Those the user created in the security config) and then select which applications follow those rules.. So notes could be no security/no password or it could be 'ask me each time'... Calendar could be the same.. File browser could be heavy encryption with picture.. Etc.. Then each application does not need to know anything about the security levels at all. It just calls the save information api (whatever that is) and hands dbus the data to save. The save mechanism looks at the request and notes the application its coming from and then hands it off to the security engine to encrypt appropriately.. And then it hands it back at which point the save data mechanism can write it to the file system.. Reading is the same.. Except the read data mechanism looks at the application making the request and in the case of ask me data looks at the data to see if its encrypted/secured.. If so it tells the security mechanism which asks the user for the appropriate level of password information and then decrypts or authenticates the read action and the user gets to read the data. Combined with the sudo idea about a configurable amount of time for authorized idleness... And add to it the ability elevate permission levels.. So that once you have authorized to read highly sensitive information you can also just read password protected but not encrypted info.. And then I think it might meet everyones needs. By default no security is provided and none required.. Once configured it could handle almost any level of detail for encryption assuming someone wanted to go through the trouble of making it happen that way. And you could build new security mechanisms that plug into the architecture and allow for some people gesture authentication and for others hand writing codes or voice codes or numeric codes or anything. Um... Yeah.. Ok so that might be 10 cents worth. I like this -- except it doesn't quite match my sample-of-one user study. My degree-of-security-wanted is by data, not by application. The same app is used for things like VINs and tire sizes and oil filters for cars (no security) and for student presentation grades. It's also not clear to me that more than two levels of security (open/password protected) are needed -- where password protected means encrypted using whatever scheme we've got. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
Joe Pfeiffer wrote: snip It's also not clear to me that more than two levels of security (open/password protected) are needed -- where password protected means encrypted using whatever scheme we've got. Personally. Unencrypted: Anything that you might want on display on the screensaver and don't really care if others see it. 4 or 5 digit PIN: GPS track logs, phone numbers, last numbers dialed Passphrase: Audio recordings of all calls. cookies and autofill data for https sites. restricted list of phone numbers. ssh keys to my home system. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proposal: Personal Data Encryption (maybe SoC?)
On Mon, 19 Mar 2007 22:09, Joe Pfeiffer wrote: I like this -- except it doesn't quite match my sample-of-one user study. My degree-of-security-wanted is by data, not by application. The same app is used for things like VINs and tire sizes and oil filters for cars (no security) and for student presentation grades. It's also not clear to me that more than two levels of security (open/password protected) are needed -- where password protected means encrypted using whatever scheme we've got. See that's where the 'ask me' setting comes in.. If an application can store encrypted vs not then its an 'ask me' then on a per data basis you can set it. The multi level security might not be necessary, but this scheme can handle it just in case. The best part is that if you don't want it, you don't use it. And those that do want it, can use it and its all completley transparent to the applications. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
