"unintelligble" that are favourable to the person being
investigated).
But I expect you're right, it's too difficult and not practical. Not
compared with the alternatives. I like secure VOIP initiated from
encrypted SMS. A wireless connection is always available in a big city.
O
Flemming Richter Mikkelsen wrote:
There are no simple voice transforms at all that will get through the codec,
and actually encrypt.
Voice changing is possible, but encryption is not.
You _cannot_ - for example - exepect frequency inversion - to get through
the codec chain.
What about correlat
> There are no simple voice transforms at all that will get through the codec,
> and actually encrypt.
> Voice changing is possible, but encryption is not.
>
> You _cannot_ - for example - exepect frequency inversion - to get through
> the codec chain.
What about correlating (multiplying) the inpu
Crane, Matthew wrote:
Yes, I understand that, that is why I'm thinking of this approach. My
idea was to use analog voice transforms and their inverse with
properties that would preserve most of the codec performance. But it
would be awfully difficult to sync up the inverse on the other end
with
ction, I expect that with voice calls that delay can
be added and removed without warning.
But in terms of complexity and chance of success, it does seem like the
encrypted SMS is both practical and feasible, compared to any sort of
voice encryption.
Maybe a composite solution? Secure voip se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
>>> UID:[EMAIL PROTECTED]
>> Thanks... Just one thing: how is generated the UID data?
>> It seems something like:
>> UID:[EMAIL PROTECTED]
>> Well, how is calculed what I called ${id}?
> I have absolute
Am Mo 17. März 2008 schrieb Marco Trevisan (Treviño):
> Andy Green wrote:
> > Somebody in the thread at some point said:
> >
> >> Do you have some examples to post?
> >> Thanks!
> >
> > I didn't know any of this until Magnus said, but it seems it is like
> > this, additional texts appear between
Thanks... Just one thing: how is generated the UID data?
It seems something like:
UID:[EMAIL PROTECTED]
Well, how is calculated what I called ${id}?
There is an official spec for the UUID format, or several variants of it.
http://en.wikipedia.org/wiki/Uuid
Ian D
_
Andy Green wrote:
Somebody in the thread at some point said:
Do you have some examples to post?
Thanks!
I didn't know any of this until Magnus said, but it seems it is like
this, additional texts appear between additional BEGIN:VJOURNAL /
END:VJOURNAL
# cat /home/root/.evolution/memos/local/
>
> Magnus Alvestad ha scritto:
> > They are saved in evolution files in the root home directory. I don't
> > remember the exact path, but it's something like:
> >
> > ~root/.evolution/memos/memos.evo
>
> Since When I'll have a freerunner I'd like to import my SMSs saved in my
> actual mobile, I'd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Somebody in the thread at some point said:
> Do you have some examples to post?
> Thanks!
I didn't know any of this until Magnus said, but it seems it is like
this, additional texts appear between additional BEGIN:VJOURNAL /
END:VJOURNAL
# cat /home
Magnus Alvestad ha scritto:
They are saved in evolution files in the root home directory. I don't
remember the exact path, but it's something like:
~root/.evolution/memos/memos.evo
Since When I'll have a freerunner I'd like to import my SMSs saved in my
actual mobile, I'd like to know the ex
They are saved in evolution files in the root home directory. I don't
remember the exact path, but it's something like:
~root/.evolution/memos/memos.evo
--
Magnus Alvestad - Seniorkonsulent Webstep
Mob: 982 98 004 - http://www.webstep.no
Oslo - Bergen - Stavanger - Trondheim
I use Neo1973 in China
I can transcode from base64 to Chinese
in this way i can read the chinese SMS
i know the sms save at /home/root/Document/application/Qmail/mail In Qtopia
but i don't know where the SMS mesage save In the OpenMoko
--
my Blog : http://blog.chinaunix.net/u/
Flemming Richter Mikkelsen wrote:
It is just one idea. I don't know how complicated it would be. (This
would need the gsm driver to be in the kernel, but I assume it is.)
It is not. *g*
Receiving SMS is something the GSM unit makes almost autonomously.
gsmd (the driver ;) )just read
c we would block (SMS, calls, data) both incomming and
outgoing (useful if someone borrows the phone). Of course it would
need a little front-end, but that would be easy to make.
By adding an iptables kernel module, we could have something that
would be more than good enough for most of us. We would
er a call to specify spam/non-spam would be nice, but might
get annoying for users too.
Using a downloadable database of spammy phone numbers to block calls or
SMS message from could get quite large. Plus you have to deal with users
attempting to poison the database, such as the "M
ian douglas wrote:
Tilman Baumann wrote:
In my eyes, trust should be calculated automaticly, not by manually
defining trust (like pgp). Using the system could improve it.
Perhaps number of successful phone calls, and length of phone call to
add a number of trust 'points' ... the more successf
Tilman Baumann wrote:
In my eyes, trust should be calculated automaticly, not by manually
defining trust (like pgp). Using the system could improve it.
Perhaps number of successful phone calls, and length of phone call to
add a number of trust 'points' ... the more successful calls over some
you still need your own defense because they
obviously are getting away with it, for a while at least; or they
don't know that it's a cell. But in practice I don't really get
telemarketing calls on my cell, and nowadays seldom get them at home.
I have gotten SMS spam though. I guess
relations
for my spam filter...
And by the way. Spamassassin (or better something 'lighter') for sms
sounds like a really really good idea...
Just my 2 Eurocents
Tilman
PS: This calls for a interception API on the phone. Fighting spam would
not be the only thing that
for military or frat recruiters who regretfully obtained
the number legitimately would be pretty nice though.
SMS spam is one thing, but I'd wager individual blocking for calls is
more useful then block lists.
--
Joseph Jon Booker
signature.asc
Description: PGP signature
_
On Mon, Feb 25, 2008 at 2:18 PM, Heikki Sørum <[EMAIL PROTECTED]> wrote:
> from Matilda in Canned Meat Marketing. Matilda has created an software
> system that automates calling and displays a unknown caller ID, then
...
> 3rd party ruggedized Moko Case!) he tags the calling ID with "Deceptive
>
On Mon, Feb 25, 2008 at 4:47 PM, Steven Kurylo <[EMAIL PROTECTED]>
wrote:
> On Mon, Feb 25, 2008 at 1:18 PM, Heikki Sørum <[EMAIL PROTECTED]>
> wrote:
> > Hi everyone! Today I got another proposal for useful
> > applications that would make an open mobile outshine
> > "oldsch00l" mobiles.
>
> Wh
On Monday 25 February 2008 22:39:04 ian douglas wrote:
> Being able to do this within OpenMoko would be pretty slick too, though
> you won't really gain anything by marking SMS messages as spam -- you're
> still paying for the incoming message whether to tag it as spam or not
On Mon, Feb 25, 2008 at 1:18 PM, Heikki Sørum <[EMAIL PROTECTED]> wrote:
> Hi everyone! Today I got another proposal for useful
> applications that would make an open mobile outshine
> "oldsch00l" mobiles.
While I've never thought of taking it that far, this is one of the
prime reasons I will be
Heikki Sørum wrote:
In my ideal world: Alice gets a OpenMoko, and then starts
getting annoying calls from Peach Corporation that would like to sell
here an Peach M-Phone. As Alice dislikes Peach Corporation, she tags
any sms/mms and caller ID's with a "Marketing Call" tag.
One
Hi everyone! Today I got another proposal for useful
applications that would make an open mobile outshine
"oldsch00l" mobiles.
The leader of the Norwegian EFF chapter posted som days in
frustration a question whether there was any kind of blacklisting/spam
filtering capabiliti
On Dec 5, 2007 2:25 AM, Thomas Wood <[EMAIL PROTECTED]> wrote:
> The latest snapshot includes the first alpha version of the Messages
> application which allows you to send and receive SMS messages.
That's good news!
> I can confirm that GTA02 fixes this - you do not even nee
I did not know they charge you extra for SMS in the US, since SMS
is the data transfers that happens between pressing the 'call'
button and the connection to the other phone (actually SMS was a
hack found out by Nokia people back in the '90's)
It was part of the GSM sta
I did not know they charge you extra for SMS in the US, since SMS is the
data transfers that happens between pressing the 'call' button and the
connection to the other phone (actually SMS was a hack found out by Nokia
people back in the '90's)
But over here in the Netherland
the average European
> >>> mobile phone user a part of "mass", then you are wrong and yes, text
> >>> text messaging (SMS) is an absolute requirement for European mobile
> >>>
> >>
> >> Plenty of people use SMS in the US too, especia
On Wed, 2007-12-05 at 01:45 +0100, Bernhard Kaindl wrote:
> On Tue, 4 Dec 2007, Jon Phillips wrote:
[...]
>
> So can we __please__ put the thought of text messaging (SMS) being
> optional for mass __usage__ (not resting, as it's now) to rest now?
>
> Of course it's
Richard Reichenbacher wrote:
Shawn Rutledge wrote:
On Dec 4, 2007 5:45 PM, Bernhard Kaindl <[EMAIL PROTECTED]> wrote:
Maybe it is enough for the US, but if you define the average European
mobile phone user a part of "mass", then you are wrong and yes, text
text messaging (SMS
Shawn Rutledge wrote:
On Dec 4, 2007 5:45 PM, Bernhard Kaindl <[EMAIL PROTECTED]> wrote:
Maybe it is enough for the US, but if you define the average European
mobile phone user a part of "mass", then you are wrong and yes, text
text messaging (SMS) is an absolute requirem
On Dec 4, 2007 5:45 PM, Bernhard Kaindl <[EMAIL PROTECTED]> wrote:
> Maybe it is enough for the US, but if you define the average European
> mobile phone user a part of "mass", then you are wrong and yes, text
> text messaging (SMS) is an absolute requirement for European
mobile phone user a part of "mass", then you are wrong and yes, text
text messaging (SMS) is an absolute requirement for European mobile
phone users.
While some die-hard developers (even European ones) may consider SMS
an obsolete concept which was there before email over GPRS was possi
Regarding SMS, a few basic comments on how it works ...
First, there is a message service center address, that is the
link to the provider and is set with the +CSCA command.
The device (phone) can be set to allow originations (send),
terminations (receive) and broadcast type messages, set
with
Question about how SMS messages work. Does the software stack have to
perform a a seperate action to retrieve an inbound sms message, or is
the message text actually part of the alert from the gsm chip? If a
seperate action has to be taken to retrieve the sms message, then do
the phone carriers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
10-15c/SMS => that's about 60-90c per KB. Or 600-900$ per MB. Don't
think that GPRS is THAT expensive even in Canada.
Andreas
Crane, Matthew wrote:
> Ok, yea, they aren't often free, but they are often free to send even
> w
reference, Canadian $ getting closet to parity with USD lately.
Matt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mikko J
Rauhala
Sent: Tuesday, May 29, 2007 9:56 AM
To: community@lists.openmoko.org
Subject: RE: GPS+sms apps
On ti, 2007-05-29 at 0
On ti, 2007-05-29 at 09:15 -0400, Crane, Matthew wrote:
> I guess SMS is generally more accessable and tends to be a lot cheaper,
> often free, in Toronto and most of Canada.
I didn't know SMS are often free; here they cost a bundle, though a bit
less if you take a bulk deal in your m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well, it's a general problem. Depending upon your phone plan, using SMS
might make sense or not. If SMS are free, that's nice, although I doubt
you'll manage to run a ppp session with mtu 150 over it :-P
Generically speaking, SMS are
I guess SMS is generally more accessable and tends to be a lot cheaper,
often free, in Toronto and most of Canada. Phones could transmit
position continuously to a central server, or some centralized
mechanisim, and I'm thinking it would be much easier for a centralized
server program to n
You don't need GPS for that. It's a quite simple Python script (without
GUI certainly less than 10 lines) for PyS60 (Symbian S60), that checks
the GSM/UMTS cell info, and sends a SMS to your wife if you enter a
specific cell ("I'll be home in 15 minutes" or "I'm ne
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You don't need GPS for that. It's a quite simple Python script (without
GUI certainly less than 10 lines) for PyS60 (Symbian S60), that checks
the GSM/UMTS cell info, and sends a SMS to your wife if you enter a
specific cell ("I&#
Why would you need SMS - if you are running a data plan already to track
cell tower and relative position to other Neo users then you may as well
make it a self contained application.
Regards,
Dean Collins
Cognation Pty Ltd
[EMAIL PROTECTED]
> -Original Message-
> From:
Is there any existing application which combine sms messaging and GPS?
It would be pretty cool to get automated alerts whenever a particular
person is nearby, through a central machine (phone, desktop). Or to use
some sort of automated homing application, where two people are able to
lock to
SMS is lost.
iirc, thats how mms works. it sends a special kind of sms that a mms
enabled device will pick up on. said sms points to a wap server that
hands out the mms to the phone.
at least thats my experience when getting a mms on a "very" old phone.
another option is that if a
One of the things that I have just received recently is that, somehow,
the network detected that I had a phone that was not able to receive a
MMS. It just sent me a text message with a web address in it to
retrieve it. This implementation is not too good as it immediacy of
SMS is lost.
Can the
On 3/22/07, Ian Stirling <[EMAIL PROTECTED]> wrote:
Andreas Kostyrka wrote:
> * Jonathon Suggs <[EMAIL PROTECTED]> [070321 22:58]:
>> Andreas Kostyrka wrote:
>> My challenge is just to think bigger. Think how this could be
incorporated to work with *any* phone. Then you can have a much larg
ble to tune it.
First, I'm not a SMS user (I use email.), so you can take this comment for
whatever its worth.
This is just a very general statement, but I personally think that designing features that will only work with other OpenMoko phones is a bad idea. Yes, there are some idea
;more often would be able to tune it.
> >
> First, I'm not a SMS user (I use email.), so you can take this comment for
> whatever its worth.
>
> This is just a very general statement, but I personally think that designing
> features that will only work with other OpenMoko
st of ideas.
Sorry if I completely missed the point.
So one approach might be to investigate the java implementation on other
phones and see if you can gain access to sms for receiving and sending
messages. Then you could write it to test the waters on openmoko.. Then
build a java version f
attle fighting uphill isn't the best of ideas.
I agree, instead of using a non standard SMS format, you better simply go the
Jabber/$IM_OF_CHOICE route for which there are Java client's that would run
on 100s of million cell phones right now. To make matters worse, it's not
rea
Andreas Kostyrka wrote:
...plus probably a system that would automatically upload/download moko-ness
information.
This way all mokos could keep in touch, and people that switch phones
more often would be able to tune it.
First, I'm not a SMS user (I use email.), so you can take
* Mikko Rauhala <[EMAIL PROTECTED]> [070321 01:40]:
> 'lo
>
> Didn't appear in the wiki, so I figured I'd throw it out there first:
> compressed SMS for when a persistent TLS-encrypted and -compressed
> Jabber connection just isn't there (eg. if it would
Mikko Rauhala wrote:
'lo
Didn't appear in the wiki, so I figured I'd throw it out there first:
compressed SMS for when a persistent TLS-encrypted and -compressed
Jabber connection just isn't there (eg. if it would be too expensive in
a particular locale), but you need
'lo
Didn't appear in the wiki, so I figured I'd throw it out there first:
compressed SMS for when a persistent TLS-encrypted and -compressed
Jabber connection just isn't there (eg. if it would be too expensive in
a particular locale), but you need to send "long" text
go. So sometimes it happens that I see them in the same
train - but even when we use the same train, sometimes only at the
end of the trip...
So when I enter the date and time when I will use the train, someone
will join...
It was just an example how the Neo1973 could serve others information
reque
it on the screen would solve that problem.
--Organising--
Ways to organise your SMS inbox similar to email, so you could filter certain
contacts sms into the Work folder for example and others to Personal
--Stats--
A stats sheet that gives you a summary of your texting habits, like telling you
wh
s feature with others.
>
> Why not go all the way and use Jabber instead? Surely that should be cheaper
> than the ripoff prices for SMS we usually see...
Of course, Jabber will be a topic, and the Jabber protocoll will be
a posibility to chare "accessable status information"
&
your day-to-day info in such detail
2) How to logically secure access to that information once it is present
This goes a bit beyond the medium (SMS) and into the mechanism (???).
The latter interests me more as assuming you have this information
available to SMS, you have it available for any other
Dnia czwartek, 7 grudnia 2006 19:44, Gabriel Ambuehl napisał:
> Why not go all the way and use Jabber instead? Surely that should be
> cheaper than the ripoff prices for SMS we usually see...
As long as phone will be able to keep GPRS session connected all the time
it could be good. I p
he ripoff prices for SMS we usually see...
pgpZbYMb2ib2i.pgp
Description: PGP signature
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Salve!
Oh I missed the idea that I like most "encrpyted SMS"
- I already thought to start to do it with J2ME
just charing 1 MB random data with a friend/partner/parents
and add the first 160 chars to the first SMS,
the second 160 chars to the second
With Neo1973 to Neo1973 it wo
x27;m realistic that most of this ideas would be only for
next and after, after next hardware generation or only for selfmade
hardware hacks.
Comming back to the potential of the Neo1973 just with GNU/Linux on
the SoC and GSM/GPRS and AGPS - something nearly every phone has
SMS.
IMHO SMS has much
501 - 567 of 567 matches
Mail list logo
