Live in southern Ontario? Attending dinner meetings is free.

PegaSoft's February Dinner Meeting

Date: February 15, 2007
Location: Linux Caffe


Attendance

Ken B, Mike H, Gord H, Richard, Gregg, Chris A J, Clifford I, Mike, Amanda


Meeting Business

PegaSoft Buttons

Thanks to Colin M for designing and printing up pin-on buttons for the
meetings.


PegaSoft Mailing List Problems

No problems were reported with the new Mailman mailing lists.

Clifford recommended "Drupal Organic Groups", a combination of web forums and
mailing lists.


PegaSoft at LinuxWorld

Colin M offered a free both to PegaSoft for this year's LinuxWorld conference.
Ken B asked for volunteers on the mailing list but no one was available.  The
booth had been turned down.  Ken B said he'd pursue the booth if anyone at the
meeting was interested in volunteering to man the booth.  The booth could be
used to promote personal projects.


Personal Introductions

Due to the number of new people, each person introduced themselves.


PegaSoft Introduction

Ken said the meeting preparations were rushed because he had to deal with
family problems over the past few weeks.

Ken gave a brief background talk on PegaSoft.

Clifford was confused by PegaSoft's direction.  Ken said PegaSoft was in a
state of transition (as indicated in the Lone Coder's September "PegaSoft
Revolutionary Karaoke Polka" column).

Clifford thought that PegaSoft was an alliance of consultants.  Ken
explained that, with the backing out of the first client, most of the
consultants no longer attended meetings and PegaSoft didn't have the time or
money to market itself.  Clifford believed that an umbrella group for an
alliance of independent consultants often fails because there are too many
developers and not enough people doing marketing.  Such groups "crumble
under their own weight" as arguments break out amongst the consultants and
not enough work comes in.  Ken pointed out that the idea never got beyond the
discussion stage because the first client pulled out.  Without money to hire
professional marketers or to do promotions, it was just an idea.  Clifford
believed PegaSoft failed in its umbrella group concept because of a lack of
will and skill.

Clifford said that the best bet for developers was to work as independent
consultants.  Back room programming jobs are virtually non-existent.

Clifford talked about the importance of developers marketing themselves.  He
recommended reading books by Seth Godin (http://www.sethgodin.com/).  Mr. Godin
talks about web marketing and seeding ideas.  As an example, Clifford described
an acquaintance who started up he web site promoting businesses in his local
area.  Web sites should target the clientel and PegaSoft's web site didn't
target anyone. [KB: The PegaSoft web site is intended to target developers,
not clients.]  Clifford thought that the web site needed more content.  [KB:
The web site has hundreds of pages of content.]

Ken agreed that most consultants don't know how to market themselves.  Ken
suggested some consultants became consultants to boast they were experts in
their fields while not taking the time and research to recruit business and
make money.  However, Ken also believed that marketing, although necessary,
was not a "magic bullet" to guarantee work in a bad economy.

When Ken mentioned that he learned how to program Java applets over his
Christmas holidays, Clifford said this was an example of developers spending
time on minute details instead of marketing themselves.  There's too much
information to learn it all so programmers must specialize.  [KB: compare with
the Lone Coder January 2006 column, "The Tyranny of the Label", where being a
skilled expert is actually a liability in finding work in computers.]  Ken
said that he agreed in principle but that criticizing him over experimenting
with Java during his holidays was not a good example.  His regular time was
not taken up with experimenting.

Clifford said Ken must have had trouble looking for work because of his web
site content.  [KB: I responded to this kind of statement in the Lone Coder
"PegaSoft Revolutionary Karaoke Polka article.]

Ken suggested that if Clifford wanted to talk more about self-marketing, he
was welcome to do a presentation at a future PegaSoft meeting.  Clifford
agreed.

Chris agreed to do a talk on shell scripting at a future PegaSoft meeting.


Open Forum - Industry Quote
(Opinions are those of the participants.)

We can't afford to give away everything for free".  (Sergey Brin on
Google's plan to charge for extra Gmail storage)

Ken pointed out that Gmail has 2 GB of space for messages and he had never
come close to using up the space.  Ken wondered if Google was really going
to make any money.  Chris agreed that 2 GB was a lot of space, but some
people used the Gmail file system which turns Gmail into a cheap storage
device.  Even with the charges for additional storage, Gmail might still
be cost-effective.

It was also pointed out that the Gmail spam folder, which wasn't counted in
the 2 GB, is now being counted.  Spam constitutes over 50% of the email on
the Internet.


Open Forum - Linux in the News

Skipped for lack of time.


Software Demonstration - Audacity (Ken B)

Not prepared.


PegaSoft Member Projects

 
Business Shell (BUSH) (Ken B)

No work.


On-line Game Project

Ken experimented with Java applets during the Christmas holidays.  The
DotDoodler eat-the-dots game was posted on the web site.


Richard's Online Game Project

Richard and Gregg have been working on an on-line game project.  Screenshots
can be seen at www.fondusis.com.


Atomic OS

Scott E is now working full-time on Atomic OS (November's presentation).


Discussion: Pivacy Preferences Project - P3P (Ken B)


- P3P is a standard way for a web site to describe its data security
- "Privacy Policy" links on web sites only provide a human-readable
  description of the policy
- modern web browsers read the policy information and use it
  - in theory, a user could configure their browser to warn them if they visit
    a page where his/her phone number was being collected to distribute to a
    third-party

- consists of 3 parts
  - the human-readable "Privacy Policy" HTML web page
  - a summary of the privacy policy in an XML file
  - a "compact" privacy policy that is encoded in the HTTP message to the web browser

- the privacy policy HTML web page
  - human-readable version of the data security policy
  - what information is gathered, how it is shared, how long is it kept, how to ask questions
  - the policy can be a summary of the site or a policy for the page it's linked to


Thank you for visiting our web site and reviewing our Privacy Policy. We are
committed to safeguarding the privacy of our users while providing a
personalized and valuable service. This Privacy Policy explains our web site
data processing practices. The Policy is also required under the P3P privacy
standard supported by some web browsers.

Our web site, www.dbsfinancial.ca (the "Site"), is provided to you by the DBS
Financial Management ("we," "us" and "our"). Your privacy is important to us. It
is our policy to protect your information (as defined below) and to use it in
accordance with this Privacy Policy. This Privacy Policy only covers our on-line
privacy practices.

1. Information We Collect From You. We automatically collect information about
   your Internet connection, such as: (i) the IP address of the web site from
   which you linked directly to our Site; (ii) the date and time you access our
   Site; and (iii) the pages you visit; and (iv) the date, time and page from
   which you exit our Site. Such information does not identify you personally.
   We use this information to monitor the effectiveness of the Site, identify
   areas of interest and consider potential improvements to the Site.
2. Sharing Your Information. We do not disclose information to third parties,
   except as follows: (i) we may share information with our site host for
   administrative purposes; (ii) we may provide information if required to do so
   by law or if we believe that such disclosures will promote compliance with
   the law; or (iii) we may provide information to protect the personal safety
   of a person or to protect our property rights or those of any other person or
   entity.
3. Linked Sites. We may provide links on the Site to other sites of interest.
   We do not review or endorse the content of these sites or guarantee that they
   will abide by this Privacy Policy. Your use of such linked sites is subject
   to the terms and conditions and privacy policies of the providers of those
   sites. We encourage our users to be aware when they leave our Site and to read
   the privacy statements of each Site that collects Personal Information.
4. Contact Us. You may contact us as through the instructions on the Contact Us
   web page on the Site.
5. Changes To Policy. We may change this Privacy Policy from time-to-time. If we
   do make a change, we will post the revised Privacy Policy on this Site. We
   encourage you to review this Privacy Policy periodically. Questions, comments
   or complaints about our privacy policies should be submitted to us by one of
   the methods listed in Section 4 above.


- the XML policy file
  - the layout is described at http://www.w3.org/TR/P3P/
  - the file is located in a standard location (/w3c/p3p.xml)
  - the standard location can be overridden with a  tag in the web page
  - <link rel="P3Pv1" href="http://www.pegasoft.ca/client/dbs/w3c/p3p.xml">
  - the location can also be specified in the HTTP header
  - P3P: policyref="http://www.pegasoft.ca/client/dbs/w3c/p3p.xml"
  - each policy specification can apply to one page, a group of pages, or the entire site
  - a simple example for the Privacy Policy above


<META xmlns="http://www.w3.org/2000/12/P3Pv1">
  <POLICY-REFERENCES>
    <EXPIRY max-age="864000"/> <!-- 10 days -->
    <POLICY-REF about="#policy1">
      <INCLUDE>/*</INCLUDE>
      <COOKIE-INCLUDE>* .dbsfinancial.ca *>/COOKIE-INCLUDE>
    </POLICY-REF>
  </POLICY-REFERENCES>
  <POLICIES>
    <POLICY discuri = "http://www.pegasoft.ca/client/dbs/privacy.html" name="policy1">
    <EXPIRY max-age="864000"/ <!-- 10 days -->
    <ENTITY>
      <DATA-GROUP>
        <DATA ref="#business.name">DBS Financial Management</DATA>
      </DATA-GROUP>
    </ENTITY>
    <ACCESS><nonident/></ACCESS> <!-- no identified data is collected -->
    <STATEMENT>
      <PURPOSE><current/><admin/><develop/></PURPOSE>
      <RECIPIENT><ours/></RECIPIENT>
      <RETENTION><indefinitely/></RETENTION>
      <DATA-GROUP>
        <DATA ref="#dynamic.clickstream"/>
        <DATA ref="#dynamic.http"/>
      </DATA-GROUP>
    </STATEMENT>
  </POLICY>
  </POLICIES>
</META>


- POLICY-REFERENCES section - where a policy applies and for how long
  - EXPIRY - how long the web browser can cache the policy (default 24 hours)
  - POLICY-REF - information about a particular policy
  - INCLUDE - files or directories covered by the policy (/* - the entire web
    site)
  - EXCLUDE - files or directories not covered by the policy
  - COOKIE-INCLUDE/EXCLUDE - browser cookies (saved on the user's computer) that
    are covered by the policy
  - <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/> is all cookies
  - many other sections including METHOD (get/put for web forms), multiple
    language support, etc.
- POLICY - what is collected, by whom and why
  - EXPIRY - normally should reflect expiry in POLICY-REF
  - ENTITY - who is collecting the information
  - ACCESS - what is collected
  - PURPOSE - why the information is collected
  - RECIPIENT - who gets the information
  - RETENTION - how long the information is held
  - DISPUTES - who handles questions about the data what what they will do
    about it (e.g. could be a third-party mediator organization)
  - #dynamic.clickstream - the information in web server logs (virtually
    always applies)
  - #dynamic.http - the information sent by a browser (virtually always
    applies)
  - again, many additional tags
  - others include clienevents, cookies, miscdata, searchtext or
    interactionrecord
  - technically, "no data collected" is not the same as "only web server logs"
    but how do you coordinate with your ISP if you are a small business?

  - the XML file allows for multiple policies for different parts of a web site
    a more complicated policy example


<POLICIES xmlns="http://www.w3.org/2000/12/P3Pv1">
<POLICY discuri="http://www.stevesstore.com/privacy.html"
 name="policy1">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">Steve's Store</DATA>
   <DATA ref="#business.contact-info.postal.street">
         123 Steve Street</DATA>
   <DATA ref="#business.contact-info.postal.city">Bethesda</DATA>
   <DATA ref="#business.contact-info.postal.stateprov">MD</DATA>
   <DATA ref="#business.contact-info.postal.postalcode">20814</DATA>
   <DATA ref="#business.contact-info.postal.country">USA</DATA>
   <DATA ref="#business.contact-info.online.email">
         steve@stevesstore.com<</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.loccode">301</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.number">
         3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <ACCESS><nonident/></ACCESS>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
    service="http://www.PrivacySeal.example.org"
    short-description="PrivacySeal.example.org">
   <IMG src=http://www.PrivacySeal.example.org/Logo.gif
        alt="PrivacySealExample logo"/>
   <REMEDIES><correct/></REMEDIES>
  </DISPUTES>
 </DISPUTES-GROUP>
 <STATEMENT>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream"/>
   <DATA ref="#dynamic.http"/>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>
</POLICIES>


- a P3P validator is located at http://www.w3.org/P3P/

- the P3P compact policy
  - problem with standard P3P: cookies are sent with the web page by the web
    server, before the browser has a chance to fetch the privacy policy file
  - considered an optional optimization
  - uses a series of abbreviations for policy elements
  - e.g. remedies = COR (<correct/>), MON (<money/>, LAW (<law/>)
  - P3P: CP="NON DSP ADM DEV PSD IVDo OUR IND STP PHY PRE NAV UNI"
  - the life span is the life span of the cookie

- problems
  - businesses don't see the value in data security (that is, no monetary
    rewards)
  - businesses see the policies as making them vulnerable to lawsuits
  - legal uncertainties: what if the XML file doesn't match the text Privacy
    Policy?
  - difficult to validate: have you covered everything?
  - difficult to keep up-to-date: if you add a cookie or a web form to a page,
    you'll have to update the privacy policy
  - getting businesses to adhere to their own policies is not always simple
    (i.e. how data is treated in databases)
  - P3P compact is a boiled down version of the full-policy, which may lead to
    conflicts with the real policy
  - P3P compact difficult to implement on simple web sites (must configure in
    the web server)
  - web browsers have been slow to adopt P3P support
  - Mozilla can be built with P3P support (an option), IE 6/7 support P3P
    compact, Firefox doesn't support it

- current status
  - P3P 1.1 is on hold

- conclusions
  - data security is an important issue
    - P3P doesn't enforce any security, is expensive and cumbersome
    - not practical for the real-world
  - P3P can be used for small web sites to make them look professional
  - until browsers fully support P3P, it's not important for web developers
    to adhere to P3P

Clifford asked how P3P related to openid.org [KB: openid.net].  Ken
suggested they represented two sides of the same issue, but he was not
familiar with openid.org.

Clifford mentioned "translucent databases": encrypting data with a key (like
GPG) so only authorized people could unlock the data in columns.  Both Ken B
and Chris recently created databases with encrypted credit card information.
Ken used an MD5 hash so that credit cards could be confirmed without the
actual number being stored.


Next Dinner

Unless otherwise notified, the next PegaSoft dinner meeting is
Thursday, March 15, 2007.  Location: Linux Caffe