[kictanet] Manual Backup and Elections 2017: Is the CS ICT Honest

John Kieti jkieti at gmail.com
Sat Dec 31 00:37:52 EAT 2016


Dear Listers,

I just posted my thoughts on this in a different thread (seen this later).
Apologies for advancing the separate but related thread.

Much has been argued about the EVID component and why it should be
de-linked from internet connectivity arguments. That bit should be obvious
to anyone purporting to give an expert ICT opinion. Any argument to the
contrary should be scrutinized for dishonesty and lack of professionalism.

May I be allowed to emphasise a point in my earlier post about the
Presidential Vote tally transmission. Am afraid its essence may not be
fully understood. This subsystem becomes critical to the extent that it
helps prevent scenarios of vote tallies being altered (later) to "massage"
presidential results a certain way.

The electronic transmission of results helps preempt the kind of cheating
which is accomplished through bribing presiding officers and agents of
candidates to alter the physical forms involved (Form 34 and Form 36?).
Once the tallying is done and the results are announced in the view of
party agents, election observers and the general public, if the same are
not instantaneously transmitted for further aggregation nationally, crooked
people get a time window and convenience to bribe their way to alteration
of the physical forms. This is likely in the transitional period before
actual forms are physically transported for regional or national
aggregation.

In 2013, many such forms were reported to have disappeared altogether. Such
is the likely expediency of election crooks.

The main point here is that the electronic tally transmission subsystem is
crucial. The additional point is that IEBC can isolate specific risk areas
for this subsystem and either  reinforce it with redundant links, or work
with service providers and the universal access fund for investment in new
kind of connectivity as is necessary. This is also to bear in mind
Washington's point that the digital footprint of presidential tallies per
polling station should be extremely small. I think it might not even exceed
a Kilobyte if the system is adequately optimised for efficient data storage
and transmission.

The above said, the electoral law amendment also happens to be an
opportunity to reinforce certain things. For instance, it may be necessary
to require the IEBC to procure a mirror server, hosted in Europe or
somewhere. It could even be some kind of third party assurance service
considering the level of trust that IEBC enjoys.

Such server level redundancy should reassure political players that if the
data elements in both servers remain identical after postings of the same
data combinations from the 40k or so polling stations, then likelihoods of
a hacked server are reduced. Of course the political players can insist on
availability of both server logs (or equivalent audit trail) to verify
against possible "server hacking".

Am unsure about the Safaricom VPN used in 2013 but there might also be need
for some kind of redundancy as regards the data transmission paths used. We
need a solution to the unlikely story of jammed Safaricom network cells
(which supposedly materialised in 2013).

More importantly though, the ICT fraternity still needs a session to be
appraised on exactly what went wrong in 2013. Those are my extra 10 cent
thoughts for 2016 as we try and save our profession from ridicule.

Enjoy 2017!



On Dec 30, 2016 21:16, "Odhiambo Washington via kictanet" <
kictanet at lists.kictanet.or.ke> wrote:

> Walu,
>
> I read your views, but I have one or two observations:
> *You say "Conversely, if the RTS fails but the BVR and EVID work
> perfectly, there should be less cause for alarm.  Essentially, the three
> subsystems have a symbiotic relationship that can be used to validate or
> cross-check each other."*
>
> => I do not clearly get the symbiotic relationship between the three
> systems as far as the main issues of contention (EVID) are concerned.
> If the systems are interconnected, then, looking at it from an SQL
> perspective, the RTS system borrows only one column from the BVR tables -
> Total Registered Voters in a particular Constituency, which I believe is
> just a factor for cross-checking the results (reminds me of Tiaty saga).
> However, this isn't necessarily part of the critical system that is
> supposed to stop dead voters from resurrecting and voting! I therefore
> think that we can mentally (or even practically de-link the RTS from the
> EVID to stop this insistence on connectivity, which gives birth to the
> "manual backup", no?
>
> *You say "Sometime the failure is maliciously engineered, while other
> times it is a reflection of the genuine weakness inherent within man-made
> systems."*
>
> ==> With specific reference to EVID, I am of the opinion that it is pretty
> easy to mitigate failure of the system by having 3 sets of the system,
> which is affordable. That would address the "technical failure", but not a
> human/maliciously engineered failure, because the humans can kill the three
> or even all of the equipment. If they do this (corrupt the static DB - as
> that is the only show-stopper), then really, there should be no voting. I
> hope that doesn't happen. We still don't need 3G/4G/VSAT for this.
>
> *You say "So Cord, just as prescribed for Jubilee, should be discussing
> what level of electronic failure is acceptable, beyond which the results
> can no longer be acceptable given the potential exposure to manipulation
> that would arise from the manual alternatives."*
>
> ==> Jubilee are advancing/contemplating the imaginary failure of
> connectivity occasioned either by absence/failure of fast network (3G/VSAT)
> or Al Shaabab knocking off what is there. This is more like making a
> nightmare a reality instead of the dream that it is. CORD is insisting that
> EVID should be used without the option of the "manual backup" and we all
> know that EVID doesn't require this connectivity, which supports the CORD
> argument.
>
> *You say "On the other hand, electronic voter identification (EVID) and
> the results transmission system (RTS) are quite time-sensitive. If they
> failed, manual intervention may be the only option available"*
>
> ==> I still insist that EVID has very little to do with RTS. EVID is being
> used statically. The equipment, at most, has the constituency register, not
> the whole national register, and at the least, has just the
> registration/polling centre register. RTS is a system that kicks in later,
> once EVID has completed its role. RTS waits for data from humans -
> clerks/agents/presiding/returning officers. They can all congregate at
> the County HQ and send this data. Most County HQ have 3G. If they don't,
> VSAT is something that can be set up in less than 1 hour!
>
> Your other view go well with issue about addressing possible failures, but
> in no way support the "Manual Backup" for EVID. This manual backup thing is
> a red herring, visible immediately you de-link connectivity from the debate.
>
> Which brings me to your conclusion:* "So who is right and who is wrong?
> Unfortunately, both sides are right and at the same time, very wrong."*
>
> ==> That's because we are not there to talk to them and enlighten them.
>
> Hey, doesn't Jubilee/CORD have ICT experts in their stables/secretariats
> though?? :-)
>
>
> On 30 December 2016 at 19:55, Walubengo J via kictanet <
> kictanet at lists.kictanet.or.ke> wrote:
>
>> @Barrack,
>>
>> My views and solutions were shared ealier. But just incase listers did
>> not read or have questions, you can find them here.
>>
>> WALUBENGO: On electronic polling, both Cord and Jubilee are
>> <http://www.nation.co.ke/oped/blogs/dot9/walubengo/2274560-3492668-549k98/index.html>
>>
>> WALUBENGO: On electronic polling, both Cord and Jubilee are
>> Nothing stops the opposition from abusing a failed system, but the
>> incumbent always has an upper hand
>>
>> <http://www.nation.co.ke/oped/blogs/dot9/walubengo/2274560-3492668-549k98/index.html>
>>
>>
>> walu.
>>
>>
>> ------------------------------
>> *From:* Barrack Otieno via kictanet <kictanet at lists.kictanet.or.ke>
>> *To:* jwalu at yahoo.com
>> *Cc:* Barrack Otieno <otieno.barrack at gmail.com>; JImmy Gitonga <
>> jimmygitts at gmail.com>
>> *Sent:* Friday, December 30, 2016 6:26 PM
>> *Subject:* Re: [kictanet] Manual Backup and Elections 2017: Is the CS
>> ICT Honest
>>
>> Dear all,
>>
>> In the meantime, we encourage all of you to raise the substantive
>> issues you have the way Washington and other colleagues have done. We
>> have started collating the views for submission to the Senate next
>> week.
>>
>> Best Regards and wishes for the new year
>>
>> On 12/30/16, Collins Areba via kictanet <kictanet at lists.kictanet.or.ke>
>> wrote:
>> > Let's dissect the problem into pieces.
>> > 1: voter registration: collecting details, photos and fingerprints.
>> > (Multiple data types)
>> >
>> > 2: verification: ascertaining that registered persons are in the system,
>> > and dead / expired ones are removed from the system. (Boolean: yes / No)
>> >
>> > 3: voting: choosing from one of several options.
>> >
>> > 4: tallying : counting the choices at the polling stations and recording
>> > the results on paper or device.
>> >
>> > 5: transmission: sending this information to regional and national
>> tallying
>> > centers.
>> >
>> > Maybe the good CS can explain how al shabbat can disable IT solutions so
>> > much that manual "backups" would suffice.
>> >
>> >
>> >
>> > On 30 Dec 2016 17:58, "Grace Mutung'u via kictanet" <
>> > kictanet at lists.kictanet.or.ke> wrote:
>> >
>> >> Thank you Wash for initiating the discussion. I also wondered whether a
>> >> complimentary system was used in voter registration and where this
>> system
>> >> resides.
>> >>
>> >> I remember a quote by the IEBC CEO during the Kenya IGF where he stated
>> >> that being a Republic based on democracy, we have made elections the
>> only
>> >> means to access power.  https://livestream.com/internetsociety2/kigf
>> >> He recalled the use of tech in the 2010 Referendum, 2013 elections and
>> >> the
>> >> various by-elections that have taken place. In the Referendum and most
>> >> by-elections, there was not much contest about use of technology while
>> >> for
>> >> 2013 some issues were raised- these included multiple registers, voter
>> >> impersonation and transparency.
>> >> The tech community has an important role to play in demystifying some
>> of
>> >> these concepts.
>> >> a) The wording of the amendment read "complimentary mechanism for
>> >> identification of voters". It has now been expanded to include
>> >> transmission
>> >> of election results "where technology deployed initially fails".  What
>> >> would this mean, in the case of identification of voters and in the
>> case
>> >> of
>> >> transmission of results? What complimentary systems were envisaged
>> here?
>> >> "Manual backup?"  The ambiguity in the wording is a challenge as it
>> >> leaves
>> >> too room for interpretation in a system of high contests.
>> >>
>> >> b) The  mischief that technology was meant to cure in elections
>> >> management
>> >> was among others allegations of voter impersonation and transparency in
>> >> management of elections. Tech is therefore supposed to achieve
>> >> simplicity,
>> >> accuracy, verifiablilty, security, accountability and transparency. Is
>> >> the
>> >> conversation about a " complimentary" system a necessary one at this
>> >> stage?
>> >>
>> >> Outside of the amendment, has anyone come across the data that CA
>> >> presented on network coverage in the counties? A visualisation of that
>> >> data
>> >> besides the polling stations would be useful in helping us identify the
>> >> specific polling stations/tallying centres that are not covered. I am
>> >> asking this because the presenters spoke of areas not covered by
>> network
>> >> as
>> >> opposed to polling stations/tallying centres not covered.
>> >>
>> >> Raha tupate na ustawi
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> 2016-12-30 13:54 GMT+03:00 Victor Kapiyo via kictanet <
>> >> kictanet at lists.kictanet.or.ke>:
>> >>
>> >>> I agree. We should put together our submissions as the ICT community
>> and
>> >>> present the same to bunge.
>> >>>
>> >>> Victor
>> >>>
>> >>> On 30 Dec 2016 13:50, "Dorcas Muthoni via kictanet" <
>> >>> kictanet at lists.kictanet.or.ke> wrote:
>> >>>
>> >>>> Thanks Walu, it's time for us to stand up.  Let's demystify this
>> tech.
>> >>>>
>> >>>> On Dec 30, 2016 1:43 PM, "Walubengo J via kictanet" <
>> >>>> kictanet at lists.kictanet.or.ke> wrote:
>> >>>>
>> >>>>> I think this is an opportunity for the ICT fraternity to take up the
>> >>>>> challenge and demystify electronic systems in elections.  I believe
>> >>>>> this
>> >>>>> forum has the most neutral platform where the media, academia,
>> >>>>> operators,
>> >>>>> regulators, government, legal and other interested parties can
>> >>>>> brainstorm
>> >>>>> on this.
>> >>>>>
>> >>>>> I propose that early in the year,  a face-2-face roundtable TV
>> /Radio
>> >>>>> broadcast (NTV, Citizen, KTN?) deliberation to break this down
>> -perhaps
>> >>>>> at
>> >>>>> Strath University (CPIT are you there?).
>> >>>>>
>> >>>>> A lot has been written on the issue of electronic systems in
>> elections
>> >>>>> but seems nobody READS, least of all politicians from both sides of
>> >>>>> the
>> >>>>> divide.  I can imagine a cast of the following:
>> >>>>>
>> >>>>> IEBC: CEO or Rep?
>> >>>>> Regulator: CEO or Rep?
>> >>>>> Operator: Safcom/Airtel/Telkom?
>> >>>>> ICT Min: Minister or rep?
>> >>>>> Academia: MMU/Strath/UoN/?
>> >>>>> Political Party: Jubilee+CORD Rep?
>> >>>>> Moderator &Broadcaster: Media (Citizen, NTV,KTN)
>> >>>>> Convenor: KICTAnet -GG are you back from holiday?
>> >>>>> Sponsors: Anyone?
>> >>>>>
>> >>>>> If we do not hijack this ICT conversation, the politicians will run
>> >>>>> with it in the wrong direction and we might find ourselves exactly
>> >>>>> where we
>> >>>>> were in 2007.
>> >>>>>
>> >>>>> walu.
>> >>>>>
>> >>>>>
>> >>>>> ------------------------------
>> >>>>> *From:* JImmy Gitonga via kictanet <kictanet at lists.kictanet.or.ke>
>> >>>>> *To:* jwalu at yahoo.com
>> >>>>> *Cc:* JImmy Gitonga <jimmygitts at gmail.com>
>> >>>>> *Sent:* Friday, December 30, 2016 1:14 PM
>> >>>>> *Subject:* Re: [kictanet] Manual Backup and Elections 2017: Is the
>> CS
>> >>>>> ICT Honest
>> >>>>>
>> >>>>> Thank you Odhiambo Washington,
>> >>>>>
>> >>>>> I have the same concerns myself. I reached the conclusion that it
>> >>>>> would
>> >>>>> be nice if "ICT Experts" could lay their hands on a BVI machine as
>> well
>> >>>>> as
>> >>>>> a and show the rest of us what the problem really is. The ERT issue
>> is
>> >>>>> a
>> >>>>> red herring. It has worked flawlessly in the bi-elections that have
>> >>>>> happened ever since. With PKI and 2 factor authentication, this can
>> be
>> >>>>> solved for election day.
>> >>>>>
>> >>>>> I am sure Victor Kyalo and Joseph Mucheru could make this possible.
>> >>>>> Call it a "Kenyans as ICT stakeholders" meeting. All Listers with
>> time
>> >>>>> will
>> >>>>> begin to be asked by their family or neighbours, what the issue
>> really
>> >>>>> is.
>> >>>>> I, for one, do not want to echo the CS's words.
>> >>>>>
>> >>>>> I think the CS and the PS should help us help them. Otherwise they
>> >>>>> will
>> >>>>> be on their own when the political vultures come calling.
>> >>>>>
>> >>>>> Regards,
>> >>>>> Jimmy Gitonga
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Message: 4
>> >>>>> Date: Fri, 30 Dec 2016 11:30:08 +0300
>> >>>>> From: Odhiambo Washington <odhiambo at gmail.com>
>> >>>>> To: Kictanet <kictanet at lists.kictanet.or.ke >
>> >>>>> Subject: [kictanet] Manual Backup and Elections 2017: Is the CS ICT
>> >>>>>        Honest
>> >>>>> Message-ID:
>> >>>>>        <CAAdA2WPFoRvjF5Bodk+sHb-P4_ rUp2AXpA9Q3zAk-UR57cqwGw at mail.
>> >>>>> gmail.com
>> >>>>> <CAAdA2WPFoRvjF5Bodk%2BsHb-P4_rUp2AXpA9Q3zAk-UR57cqwGw at mail.
>> gmail.com>>
>> >>>>> Content-Type: text/plain; charset="utf-8"
>> >>>>>
>> >>>>> Dear Listers,
>> >>>>>
>> >>>>> I am at that position where I feel very lost. In fact, I feel like I
>> >>>>> am
>> >>>>> quite detached from the reality.
>> >>>>>
>> >>>>> All along, I have keenly considered this matter that seems to have
>> >>>>> divided
>> >>>>> the country down the middle: *Manual Backup* during the 2017 voting
>> >>>>> process. From the Jubilee/govt side this is a do or die and so it
>> must
>> >>>>> be
>> >>>>> there. This govt side seems hell-bent on confusing the masses, as
>> well
>> >>>>> as
>> >>>>> the experts like the ICT Community. From the Opposition side, the
>> >>>>> agenda
>> >>>>> seems to be very clear - that of ensuring integrity of the Voters
>> >>>>> Register
>> >>>>> and stopping 'ghost voters' from ever casting their votes.
>> >>>>>
>> >>>>> That brings us to the famous acronyms - BVI (Biometric Voter
>> Register)
>> >>>>> /
>> >>>>> BVI (Biometric Voter Identification).
>> >>>>> Having been to a Voter Registration Centre (later to become a
>> Polling
>> >>>>> Station) to register as a voter, I did look at the equipment in use
>> >>>>> for
>> >>>>> the
>> >>>>> registration process. I saw the laptop which was fitted with a
>> camera
>> >>>>> and
>> >>>>> fingerprints scanner. All these require power to run. I did not
>> dwell
>> >>>>> on
>> >>>>> how they were powered, but probably there was a battery backup
>> >>>>> somewhere
>> >>>>> (besides the electricity) given that they needed to run for a whole
>> >>>>> day
>> >>>>> for
>> >>>>> several days during the voter registration process. When it comes to
>> >>>>> the
>> >>>>> Elections, they only need to run for about 11 hours. My point here
>> is
>> >>>>> that
>> >>>>> of *Backup Power* should it be that there's electricity blackout and
>> >>>>> the
>> >>>>> built-in batteries can't last the whole day. That backup is very
>> >>>>> important.
>> >>>>>
>> >>>>> However, I did not see any piece of equipment which could suggest
>> that
>> >>>>> the
>> >>>>> equipment in use required any form of connectivity back to some
>> >>>>> central
>> >>>>> server in order to function! Which now brings me to the currently
>> >>>>> national
>> >>>>> debate - Manual Backup during the Poll Day. What is it? Was the CS
>> >>>>> honest
>> >>>>> with his presentation before the Senate/Amos Wako committee
>> yesterday?
>> >>>>> Does
>> >>>>> the CS himself really believe in the content of his presentation? I
>> am
>> >>>>> asking that because I watched him and I don't believe him. I
>> actually
>> >>>>> think
>> >>>>> he mislead the committee, and hence the nation at large.
>> >>>>>
>> >>>>> Someone please prove me wrong. I am at that point where I believe
>> that
>> >>>>> the
>> >>>>> BVR/BVI does NOT require any form of connectivity and so this Manual
>> >>>>> Backup
>> >>>>> being touted by the ruling coalition side, strongly supported by
>> the
>> >>>>> ICT
>> >>>>> CS is a big lie. WHY?
>> >>>>>
>> >>>>> My very first answer: Simply put, *when there was no requirement
>> for a
>> >>>>> manual backup during voter registration, it goes without saying that
>> >>>>> there
>> >>>>> is NO NEED for on the polling day.*
>> >>>>>
>> >>>>>
>> >>>>> 1. For the issue that is in contention - BVR (used for BVI during
>> >>>>> polling)
>> >>>>> - this is a database that can be (and should be) statically stored
>> on
>> >>>>> the
>> >>>>> equipment for each polling station. We are not supposed to rely on
>> the
>> >>>>> Mobile Network to access this voters database. And every polling
>> >>>>> station
>> >>>>> can have two/three laptops/Biometrics scanner/Backup batteries to
>> >>>>> ensure
>> >>>>> that the voter identification doesn't fail.
>> >>>>> Some excuse has been fronted about some voters being mechanics, such
>> >>>>> that
>> >>>>> their fingerprints wouldn't be recognized by the BVI systems hence
>> >>>>> need
>> >>>>> for
>> >>>>> manual identification. My take on that is that every voter must
>> carry
>> >>>>> their
>> >>>>> voter's card on that day. The clerks can check that card number
>> >>>>> against
>> >>>>> the
>> >>>>> electronic system - enter it, and it will bring the person's
>> picture,
>> >>>>> ID
>> >>>>> number, etc and let him cast his ballot.
>> >>>>>
>> >>>>> 2. For electronics results transmission (ERT), this is not even
>> >>>>> necessary
>> >>>>> in the first place. We can have the results collated/announced at
>> the
>> >>>>> tallying centres after being certified - forms 36A, and such.
>> However,
>> >>>>> if
>> >>>>> the ERT must be done, the data footprint is so tiny that a 2G
>> network
>> >>>>> can
>> >>>>> be used. Besides, it can be an SMS based system, which doesn't
>> require
>> >>>>> 3G
>> >>>>> or VSAT. The results data isn't that large - it can't be in
>> Megabytes
>> >>>>> to be
>> >>>>> sincere. Well, VSAT can be used if they MUST, but this is after the
>> >>>>> voting
>> >>>>> process itself is complete, has nothing to do with BVI.
>> >>>>>
>> >>>>> The ERT and the BVR/BVI are two distinct systems. That is what I
>> want
>> >>>>> to
>> >>>>> believe. The ERT gets feedback from a manual process - of voters
>> >>>>> casting
>> >>>>> their vote, clerks/agents counting, verifying, and certifying,
>> filling
>> >>>>> requisite forms then communicating the same via some customized
>> phones
>> >>>>> which are programmed to communicate to a backend system. Am I right
>> on
>> >>>>> that??
>> >>>>>
>> >>>>> Now the big question here is, where do we need this much touted
>> manual
>> >>>>> backup where network connectivity is being used as the major
>> reason???
>> >>>>>
>> >>>>> (a) Citing terrorism and the possibility of Al Shabaab knocking off
>> >>>>> base
>> >>>>> stations seems like well thought out lie meant to cover our eyes! If
>> >>>>> they
>> >>>>> attacked an area, I doubt there will be voting in the 1st place.
>> >>>>>      And even so, the network connectivity is not required for BVI
>> so
>> >>>>> there
>> >>>>> is no disenfranchising anyone if there is no manual backup (whatever
>> >>>>> that
>> >>>>> is).
>> >>>>>
>> >>>>> (b) Citing hacking is neither here nor there for a BVR/BVI system
>> >>>>> because
>> >>>>> it's not being accessed live during the voting. It's a static
>> >>>>> database,
>> >>>>> unique to the polling station, resident on the laptop used by the
>> >>>>> clerks.
>> >>>>> The only hacking that can be done then can only be by an "insider".
>> >>>>> Quoting
>> >>>>> Victor Kapiyo from Social Media, "*I guess it's a question of trust.
>> >>>>> Trust
>> >>>>> in systems and in trustworthy people to do the right thing. For
>> >>>>> M-Pesa,
>> >>>>> or
>> >>>>> KCSE results, we trust both. For IEBC, I guess the jury is still
>> >>>>> out*."
>> >>>>>
>> >>>>> The main issue is not allowing the dead voters to rise again to vote
>> >>>>> in
>> >>>>> the
>> >>>>> presidential vote, then disappear. So the important component here
>> is
>> >>>>> the
>> >>>>> BVR/BVI, the credibility of the register and hence the vote.
>> >>>>>
>> >>>>> At what point does the BVI system require this connectivity they are
>> >>>>> talking about, which then necessitates the so called "manual
>> backup"?
>> >>>>>
>> >>>>> Did the CS ICT lie to the Senate?? Did the CAK lie to the Senate in
>> >>>>> supporting the lie from the CS??
>> >>>>>
>> >>>>> There is insincerity in this whole debate about 'manual backup' and
>> >>>>> the
>> >>>>> ICT
>> >>>>> community seems to either support it or is simply lost in the pool
>> of
>> >>>>> confusion being peddled by politicians.
>> >>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Best regards,
>> >>>>> Odhiambo WASHINGTON,
>> >>>>> Nairobi,KE
>> >>>>> +254 7 3200 0004/+254 7 2274 3223
>> >>>>> "Oh, the cruft."
>> >>>>> -------------- next part --------------
>> >>>>> An HTML attachment was scrubbed...
>> >>>>> URL: <https://lists.kictanet.or.ke/ pipermail/kictanet/
>> >>>>> attachments/20161230/4ba36a72/ attachment.html
>> >>>>> <https://lists.kictanet.or.ke/pipermail/kictanet/attachments
>> /20161230/4ba36a72/attachment.html>
>> >>>>> >
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> kictanet mailing list
>> >>>>> kictanet at lists.kictanet.or.ke
>> >>>>> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>> >>>>>
>> >>>>> Unsubscribe or change your options at
>> https://lists.kictanet.or.ke/m
>> >>>>> ailman/options/kictanet/jwalu%40yahoo.com
>> >>>>>
>> >>>>> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder
>> >>>>> platform
>> >>>>> for people and institutions interested and involved in ICT policy
>> and
>> >>>>> regulation. The network aims to act as a catalyst for reform in the
>> >>>>> ICT
>> >>>>> sector in support of the national aim of ICT enabled growth and
>> >>>>> development.
>> >>>>>
>> >>>>> KICTANetiquette : Adhere to the same standards of acceptable
>> behaviors
>> >>>>> online that you follow in real life: respect people's times and
>> >>>>> bandwidth,
>> >>>>> share knowledge, don't flame or abuse or personalize, respect
>> privacy,
>> >>>>> do
>> >>>>> not spam, do not market your wares or qualifications.
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> kictanet mailing list
>> >>>>> kictanet at lists.kictanet.or.ke
>> >>>>> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>> >>>>>
>> >>>>> Unsubscribe or change your options at
>> https://lists.kictanet.or.ke/m
>> >>>>> ailman/options/kictanet/dmuthoni%40gmail.com
>> >>>>>
>> >>>>> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder
>> >>>>> platform
>> >>>>> for people and institutions interested and involved in ICT policy
>> and
>> >>>>> regulation. The network aims to act as a catalyst for reform in the
>> >>>>> ICT
>> >>>>> sector in support of the national aim of ICT enabled growth and
>> >>>>> development.
>> >>>>>
>> >>>>> KICTANetiquette : Adhere to the same standards of acceptable
>> behaviors
>> >>>>> online that you follow in real life: respect people's times and
>> >>>>> bandwidth,
>> >>>>> share knowledge, don't flame or abuse or personalize, respect
>> privacy,
>> >>>>> do
>> >>>>> not spam, do not market your wares or qualifications.
>> >>>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> kictanet mailing list
>> >>>> kictanet at lists.kictanet.or.ke
>> >>>> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>> >>>>
>> >>>> Unsubscribe or change your options at https://lists.kictanet.or.ke/m
>> >>>> ailman/options/kictanet/vkapiyo%40gmail.com
>> >>>>
>> >>>> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder
>> platform
>> >>>> for people and institutions interested and involved in ICT policy and
>> >>>> regulation. The network aims to act as a catalyst for reform in the
>> ICT
>> >>>> sector in support of the national aim of ICT enabled growth and
>> >>>> development.
>> >>>>
>> >>>> KICTANetiquette : Adhere to the same standards of acceptable
>> behaviors
>> >>>> online that you follow in real life: respect people's times and
>> >>>> bandwidth,
>> >>>> share knowledge, don't flame or abuse or personalize, respect
>> privacy,
>> >>>> do
>> >>>> not spam, do not market your wares or qualifications.
>> >>>>
>> >>>
>> >>> _______________________________________________
>> >>> kictanet mailing list
>> >>> kictanet at lists.kictanet.or.ke
>> >>> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>> >>>
>> >>> Unsubscribe or change your options at https://lists.kictanet.or.ke/m
>> >>> ailman/options/kictanet/nmutungu%40gmail.com
>> >>>
>> >>> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder
>> platform
>> >>> for people and institutions interested and involved in ICT policy and
>> >>> regulation. The network aims to act as a catalyst for reform in the
>> ICT
>> >>> sector in support of the national aim of ICT enabled growth and
>> >>> development.
>> >>>
>> >>> KICTANetiquette : Adhere to the same standards of acceptable behaviors
>> >>> online that you follow in real life: respect people's times and
>> >>> bandwidth,
>> >>> share knowledge, don't flame or abuse or personalize, respect privacy,
>> >>> do
>> >>> not spam, do not market your wares or qualifications.
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Grace L.N. Mutung'u
>> >> Skype: gracebomu
>> >> Twitter: @Bomu
>> >>
>> >> <http://www.diplointernetgovernance.org/profile/GraceMutungu>
>> >>
>> >> PGP ID : 0x33A3450F
>> >>
>> >>
>> >> _______________________________________________
>> >> kictanet mailing list
>> >> kictanet at lists.kictanet.or.ke
>> >> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>> >>
>> >> Unsubscribe or change your options at https://lists.kictanet.or.ke/
>> >> mailman/options/kictanet/arebacollins%40gmail.com
>> >>
>> >> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder platform
>> >> for people and institutions interested and involved in ICT policy and
>> >> regulation. The network aims to act as a catalyst for reform in the ICT
>> >> sector in support of the national aim of ICT enabled growth and
>> >> development.
>> >>
>> >> KICTANetiquette : Adhere to the same standards of acceptable behaviors
>> >> online that you follow in real life: respect people's times and
>> >> bandwidth,
>> >> share knowledge, don't flame or abuse or personalize, respect privacy,
>> do
>> >> not spam, do not market your wares or qualifications.
>> >>
>> >
>>
>>
>> --
>> Barrack O. Otieno
>> +254721325277
>> +254733206359
>> Skype: barrack.otieno
>> PGP ID: 0x2611D86A
>>
>> _______________________________________________
>> kictanet mailing list
>> kictanet at lists.kictanet.or.ke
>> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>>
>> Unsubscribe or change your options at https://lists.kictanet.or.ke/m
>> ailman/options/kictanet/jwalu%40yahoo.com
>>
>> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder platform
>> for people and institutions interested and involved in ICT policy and
>> regulation. The network aims to act as a catalyst for reform in the ICT
>> sector in support of the national aim of ICT enabled growth and development.
>>
>> KICTANetiquette : Adhere to the same standards of acceptable behaviors
>> online that you follow in real life: respect people's times and bandwidth,
>> share knowledge, don't flame or abuse or personalize, respect privacy, do
>> not spam, do not market your wares or qualifications.
>>
>>
>>
>> _______________________________________________
>> kictanet mailing list
>> kictanet at lists.kictanet.or.ke
>> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>>
>> Unsubscribe or change your options at https://lists.kictanet.or.ke/m
>> ailman/options/kictanet/odhiambo%40gmail.com
>>
>> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder platform
>> for people and institutions interested and involved in ICT policy and
>> regulation. The network aims to act as a catalyst for reform in the ICT
>> sector in support of the national aim of ICT enabled growth and development.
>>
>> KICTANetiquette : Adhere to the same standards of acceptable behaviors
>> online that you follow in real life: respect people's times and bandwidth,
>> share knowledge, don't flame or abuse or personalize, respect privacy, do
>> not spam, do not market your wares or qualifications.
>>
>
>
>
> --
> Best regards,
> Odhiambo WASHINGTON,
> Nairobi,KE
> +254 7 3200 0004/+254 7 2274 3223
> "Oh, the cruft."
>
> _______________________________________________
> kictanet mailing list
> kictanet at lists.kictanet.or.ke
> https://lists.kictanet.or.ke/mailman/listinfo/kictanet
>
> Unsubscribe or change your options at https://lists.kictanet.or.ke/
> mailman/options/kictanet/jkieti%40gmail.com
>
> The Kenya ICT Action Network (KICTANet) is a multi-stakeholder platform
> for people and institutions interested and involved in ICT policy and
> regulation. The network aims to act as a catalyst for reform in the ICT
> sector in support of the national aim of ICT enabled growth and development.
>
> KICTANetiquette : Adhere to the same standards of acceptable behaviors
> online that you follow in real life: respect people's times and bandwidth,
> share knowledge, don't flame or abuse or personalize, respect privacy, do
> not spam, do not market your wares or qualifications.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.kictanet.or.ke/pipermail/kictanet/attachments/20161231/1889daf5/attachment.htm>


More information about the KICTANet mailing list