Re: [rtcweb] Encryption mandate

Dzonatas Sol <dzonatas@gmail.com> Wed, 07 September 2011 22:52 UTC

Return-Path: <dzonatas@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91B921F8DBA for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 15:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.876
X-Spam-Level:
X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=-1.543, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNbFw91XQ6wQ for <rtcweb@ietfa.amsl.com>; Wed, 7 Sep 2011 15:52:06 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16021F8DB1 for <rtcweb@ietf.org>; Wed, 7 Sep 2011 15:52:06 -0700 (PDT)
Received: by yie12 with SMTP id 12so153349yie.31 for <rtcweb@ietf.org>; Wed, 07 Sep 2011 15:53:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3i6Jt3KsfBEkweNszNDbyrOr+VbGBXX7Mp9kvcKzs0s=; b=lH3rF3MexG6hrK8CeBhnglD4mjP8kh83Sp1p7WxYkAnHmNE7kH2VPfoSVk4y9HIR9X A14JqKxP5etMoGGk7efglsjuTtII+o2XlFCCLflHWwgW/yuki7N+JKhCCffNC38D+Y6s Eq9YOx/oO2+6oLXeZ/np8J2WABjv9HADzE0BE=
Received: by 10.236.200.195 with SMTP id z43mr35731497yhn.127.1315436036480; Wed, 07 Sep 2011 15:53:56 -0700 (PDT)
Received: from [192.168.0.50] ([70.133.70.225]) by mx.google.com with ESMTPS id o43sm1735208yhe.11.2011.09.07.15.53.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Sep 2011 15:53:56 -0700 (PDT)
Message-ID: <4E67F676.4080305@gmail.com>
Date: Wed, 07 Sep 2011 15:55:50 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <A444A0F8084434499206E78C106220CA0B00FDB08B@MCHP058A.global-ad.net> <89177AB2-F721-47E4-8471-2180EDA10615@voxeo.com> <A444A0F8084434499206E78C106220CA0B00FDB34D@MCHP058A.global-ad.net> <496EE152-41F2-49AB-A136-05735FE5A9F9@voxeo.com><101C6067BEC68246B0C3F6843BCCC1E31018BF6BE2@MCHP058A.global-ad.net> <4E540FE2.7020605@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF5106423F@sonusinmail02.sonusnet.com> <4E6595E7.7060503@skype.net> <4E661C83.5000103@alcatel-lucent.com> <2E239D6FCD033C4BAF15F386A979BF510F086B@sonusinmail02.sonusnet.com> <4E666926.8050705@skype.net> <43A0D702-1D1F-4B4E-B8E6-C9F1A06E3F8A@edvina.net> <033458F56EC2A64E8D2D7B759FA3E7E7020E64DC@sonusmail04.sonusnet.com> <E4EC1B17-0CC4-4F79-96DD-84E589FCC4F0@edvina.net> <4E67C3F7.7020304@jesup.org> <4E67CE16.40403@gmail.com> <4E67D206.9010908@alcatel-lucent.com> <4E67D8AC.3030409@gmail.com> <4E67DA11.7070203@alcatel-lucent.com>
In-Reply-To: <4E67DA11.7070203@alcatel-lucent.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Encryption mandate
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Sep 2011 22:52:07 -0000

Then the outside bank wall is the ROI, not silly when you compare 
real-time events to JPEG 2K.

Security at the bank-teller, or ATM, what nobody thinks about anymore. 
We want proof that the double-entry system works between the hand-held 
mobile unit and ATMs such that the way they "solve tether-ball" TOGETHER 
is standard. Maybe no more lines at the bank; it's "wait state", like 
DDoS. Should our bank ATMs recognize our car proximities? Congestion.

Then we consider if the precursory model is "being commented upon". Do 
we have world-wide security approved by the world bank? And, 
analogue-E911? Described within IETF that works flying over celltowers.

I think the term "low-hanging fruit" is derogatory, culturally. I think 
we can still say "digital-only" if you want secure-by-default, or decide 
on import/export portal material across-state in cubic security units, 
or scale to virtual "entertainment" rooms.

How about logoff-to-delete-all login-certificates; simple 
un-federialization for security compromises: "not silly when" everybody 
does not want their "on-logoff" exploited for connection quality and 
state recovery. AI is not on the agenda, yet maybe auto-mute *coughs* 
from the signals is? As well as, other recognized input by familiar 
auto-typists, and finish the book cover with two images, or half by 
difference in geolocation.  I digress and flip-it-back, or expect 
further discussion on geo-mimes as SSRC, yet the forward-looking state 
would be by syllabic mimes for security. Maybe we still need some clear 
"technocratic" value for comparison with SSRC.

Maybe this is just some description of one relational database without 
auto-increment, yet by auto-algorithm already given and stored. Next 
generation of steady-cam that is schema-aware on quadcopter with 
quad-cores: hardware-chron shared in APU bridged with one virtual core 
of the multi-core CPU. Simply, 55' TV with RC-control of 800x600 cam 
such that the feedback window position moves within larger display area 
instead of one always-centered stabilized-viewport.

Helps to lay this out in 12D separation for the kernel with 6D of people 
you never met: a stack. The federal model puts the concepts in virtual 
bubbles, where security by binary is already known, globally. Servers 
want to simulate the "circles" put on Real3D, yet I see no certification 
that this technology is ready for BSD, yet bizarre'd for *cough* 
"fruit". I don't think their patent is gonna expire.

We can ramble on about digital-only security without algorithms as 
passwords, yet we need ones like above for default security. I question 
security technologies that orders qubits within the limits of binary 
systems. I read this up and down and feel like I cross the line if I aim 
the PIP cam and track body sections, as that is easier language for 
others to help themselves. :)

On 09/07/2011 01:54 PM, Igor Faynberg wrote:
> :)
>
> On 9/7/2011 4:48 PM, Dzonatas Sol wrote:
>> On 09/07/2011 01:20 PM, Igor Faynberg wrote:
>>>
>>>
>>> On 9/7/2011 4:03 PM, Dzonatas Sol wrote:
>>>> ....
>>>> Flip-side: contracts already force encryption, and that is one 
>>>> reason why people do not want contracts; they want open wi-fi so 
>>>> neighbors have no walls across net points.
>>>
>>> I admit, I am not one of these people... And where the neighbors can 
>>> get in, anyone else can, too.
>>>
>>
>> Experience only: we grew-up in areas without fences, only barb-wire, 
>> or "posts". In these fenced-in neighborhoods, I'm tired of the need 
>> "to pitch" openness to "anyone"; I sound evangelical now, yet others 
>> say street-smart.
>>
>> Good difference?
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


-- 
--- http://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering
Ag-Biotech, Virtual Reality, Consultant