The first issue is to decide your definition of a “public” site. Simple solutions like “anything over SSL is private” fail in both directions: some content which is not private gets served up over SSL (generally a good thing), and some content which should be private gets served up over unsecured connections (like Facebook pages). I propose the following rule instead: any page which is seen with exactly the same content by at least N different individuals will be considered public. (The value of N can be debated, but something like 6 or 9 could be a starting place.) This means that any pages that personalize to each user (even just a “Hello Janet Smith” at the top) will not get shared — that may well be exactly the behavior that is desired. And it means that any page that IS shared must at least be known to a reasonably large group (so it’s not THAT secret). This definition works reasonably well for things like Google Docs (stays private unless it is widely shared) but works poorly for things like a corporate intranet (may get shared unintentionally if too many people use the tool). Perhaps a configuration in the tool could allow certain domains to be excluded from sharing; even more likely is that no company with serious security concerns will allow a tool like this to be run on their intranet anyway.

If we accept this definition for when pages should be shared, what we have left is just a technical problem (albeit a difficult one): how can we determine whether the exact content of a certain page has been seen by at least N other users without keeping a record anywhere that it has been seen by any individual user. Storing information is not difficult; we have already accepted that this project will use a P2P storage network and use some local storage so we can store information locally or inject it into a P2P network (perhaps a different network than the one used for document storage). But some obvious approaches won’t work. We can’t store a record of what has been seen on the local disk because that would record the entire browser history. We can’t store it in the P2P network in a form that can be retrieved because then we have already made the page public. And we can’t store it tied to a particular user-id (even an anonymous one) because tying together different pages visited is an effective way to identify an individual.

I will motivate the final solution by showing a series of partial solutions, each of which gets closer to solving the problem. As a first pass, we could use a P2P network which manages a large distributed hash table in which we can anonymously store values (multiple values for a given key) and which allows us to anonymously query the values. When a user viewed a page, they would use its URL as a key, and store a hash of the page as one value for that key, along with a counter. If the counter had already reached N then the page was public and program could go ahead and store the value in the storage network. The contents of non-public pages are not stored (locally or in the network), only their hash value. Old values would be kept in the P2P network for a good long time — a month or so would be good, to be sure of capturing the “long tail” of rarely viewed content, but would eventually be cleared out to make space for newer content.

This fails because there may be malicious participants in the P2P network. As soon as a malicious participant saw a value being inserted with a count of 1 they could immediately insert it again N-1 times. Or perhaps they could even lie and return a count of N even though the count was actually 0. In either case, users would be tricked into storing content that had not actually been seen by N distinct users.

To protect against the malicious participants we need to clarify our threat model. At this stage (where we determine what content to make public), a malicious participant is one who is trying to force the user to reveal content that shouldn’t be public. Since public is defined as “seen by more than N individuals”, a malicious participant who already knew the content could just publicize it directly (or push it into the storage network), so it is malicious participants who do not know the content of the page that we are concerned with. That leads immediately to a solution: instead of trusting the count, we can store something that only a user who had actually seen the page could generate: a “proof” that the page has been seen.

Simply create N fixed blocks of text. (It could be as simple as “This is block <N>” — the content doesn’t really matter.) To obtain proof number n, concatenate the page text with block n then take the hash of it. A user will query the P2P network for all hash values stored for a certain URL. Some of them may match the hash codes for proofs 1 through N. If all of those hashes are present, then N other participants have seen this value and it should be pushed into the storage network; if not then the lowest-numbered missing value should be added. A malicious participant, not having the content, cannot generate any of these values, and they cannot determine anything from the hash values themselves (since a hash cannot be inverted).

There is, unfortunately, one problem remaining. If a single user views the same content N times, they might push all N proofs into the network all by themselves. The values cannot be tagged with an ID of the individual who found it because that would allow multiple page views to be tied together, leaking identity information. And they cannot keep a record of which sites they have visited as that too would reveal information. The solution I propose solves this problem but replaces the certainty that there were N viewers with a probabilistic solution.

When the application is first installed it will select a random “user id”. This is just a string which is used to identify the installation so we can be sure not to double-count it. There needs to be a way for the user to read the “user id” and to modify it. That way someone who frequently uses several different computers can set the user id to the same value on all of them and will not double-count views just by moving between home, work, and mobile locations. Of course, it is important that we do not link this user id to the view history.

Now, instead of creating N different blocks to concatenate with the page contents we will create K different blocks (where K is somewhat less than N). For instance, K=8 is a reasonable value; certainly we require that K is much smaller than the number of users of the crawling system. As before, query to see which of the K proofs are present in the P2P system. The system takes a hash of the user id, mods by K to select a random (but consistent) value, k (where k is in [0..K-1]) essentially dividing all users up into K groups. If the proof for k is present, do nothing: it is possible that this proof was added by this same user. If the proof for k is missing, then add it. And if the total number of proofs is more than some threshold n, then enough people have seen the page and it can be published into the storage network.

What should n be? Well, malicious participants cannot affect anything since they don’t have the page contents and can’t generate the proofs. Each actual viewer of the page has what is essentially a randomly chosen value for k. So as people view the page, they are selecting a random value of k (from 0 to K-1). This continues until n distinct values have been chosen (some may have been chosen multiple times). We observe the count of distinct values seen so far (call it m) and want to estimate the number of actual page viewers.

I’ll skip over the math and jump right to the answer: the expected number of actual viewers is:

where Hn is the n’th harmonic number:

So if we use 8 for K and we see 4 entries, that means there must have been at least 4 users seeing the same content and there was probably about 6. If we see 5 entries then there must have been 5 different individual seeing the same content and there were probably 306/35 or about 8.7. The values required can be adjusted to reach the desired value for expected number of individuals seeing the page, while keeping K small (if it is large enough that the number of participants in on bucket is small then it can potentially be used to help determine your browser history).

Well, that’s enough essays on this topic for now. If you want to learn more, you may want to check out https://github.com/titanous/constantcrawl where there may eventually be an effort to build this.

There are many different types of P2P networks for storing an retrieving files. Different networks and protocols have been designed for different purposes and thus have different strengths and weaknesses. For instance, Freenet is designed to store and retrieve files with a focus on extremely strong anonymity guarantees and resistance to files being deleted, but with weaknesses such as being particularly slow. The Gnutella network is decentralized and efficient but the usage is not anonymized. Rather than fully specifying the design of a storage network, this essay will just attempt to list the requirements. Re-using an existing protocol (or even an existing network) might be the best approach; next best would be to design one by combining well-tested components from existing successful networks.

The P2P storage network would need to support the following functions:

1. Storing values by key with some metadata. The key would be fixed and known (the URL of the content). The metadata would be small — things like the date the content was viewed and the hash of the content. The value would be the content of the URL and would not be small — it would be the size of a web page, image, PDF, or whatever was being stored. (Content larger than a certain size could be rejected.)

2. Storing multiple values by the same key. A page may change or may be viewed differently by different users. The storage network needs to support storing these multiple values.

3. Querying the metadata of a certain key. In particular, we need to query to find out whether there already exists an entry for a given URL (key) with a particular value for the hash of the content. To prevent bad actors from responding “yes” when it is really absent we may need to return the value. We would expect this query to be by FAR the most common query performed — hundreds of times more frequent than any other function the storage network would perform.

4. Retrieving the value (and metadata) for a given key. If multiple values were stored we would either return all of them or select one by metadata.

5. Querying to find out what keys had new values stored within some recent time period. This would not be used by normal users, but by organizations like the Internet Archive or Duck Duck Go that actually wanted to download the contents of this storage, thus making it into a means for crawling the entire web. It would be acceptable if the only way to perform this query were to contribute significant resources to the P2P network and also if the query were likely to be accurate instead of certain to be accurate.

Those are the only functions that would be required, but there are some broad characteristics of the P2P network that are also essential:

A. Anonymity: it should be quite difficult to determine who is performing any of calls 1 through 4. (It is OK if call 5 is not anonymous.) Otherwise, the network could be used to determine a user’s browsing history. This could be accomplished via onion routing, the elaborate approach used by Freenet, or any other solution that makes it impossible for any participant in the network to tell for sure what other members of the network are searching for.

B. Legal Protection for Stored Content. Legal liability for storing content on a P2P network can be a genuine problem. But in essentially all jurisdictions this can be avoided if the individuals participating in the network are not able to determine just what content they have. For instance, some systems break each file up into chunks which are encrypted so they cannot be understood without possessing all chunks, then store different chunks in different locations. No one person has any file on their system.

C. Reliability. The P2P system must retain its data even if peers join and drop out with some regularity. This means keeping redundant copies of everything. It must also function if some minority of the members of the P2P network are antagonists who will abuse the protocol in an attempt to harm the network. These are standard features on most P2P networks.

D. Purging of old values. The size of the P2P storage network cannot simply grow forever. So values need to be evicted eventually. Evicting values that are older than a certain age should work fairly well — if the content is still being viewed frequently it will be re-loaded rapidly and by keeping for a certain amount of time we would provide an opportunity to download the content for those using this to crawl the web. Also acceptable, but perhaps less ideal, would be automatically evicting the least frequently requested values.

That’s about it for requirements for the storage network, except that given these constraints we would like for it to be as fast as possible, especially for frequently requested values. This implies that the number of network hops should be minimized (despite this, anonymity will require a fairly large number) and may favor solutions that store frequently-requested information in multiple locations.

The next (and final) installment of this series will discuss the interesting (and challenging) question of how to tell when a viewed page can be made public.

The basic experience would be a perfectly normal browsing experience: users would launch their favorite web browser normally, would browse around the web normally and everything would “just work”. This means that clearly the system would function as a browser plug-in. Fortunately, nearly all modern browsers support some form of plug-ins. In principle, one could also develop this as a proxy, but it would be much more difficult to develop an effective UI.

An easy-to-use installation process is important if one is seeking a large user base. This means using the normal means for the platform (an installer for windows, but RPM, yum, etc for linux). It means that the installer sets up the browser plugin, allocates the disk space needed for storage, and creates the services needed to join the P2P network.

The plugin itself offers two basic pieces of functionality. One would be that it captures the content of the web as it is viewed, and (where appropriate) archives it for the crawl. The other is the benefit for the user of the plugin: it allows them to view content from the crawled archive when the normal site is slow or unavailable. (For instance, the “slashdot effect” where a smaller site is featured on a popular news site like Slashdot or Reddit and becomes overwhelmed.)

The plugin should have three basic “modes”. Any well-behaved plugin should provide an easy way turn it off, so one mode is “disabled”. Another mode would be for loading all content (or perhaps just re-loading the current page) from the archive. And of course there would be the normal mode (more on this in a moment). The mode affects the page rather drastically (changes where we are getting it from or whether we are potentially sharing it with the world) so the plugin should probably provide an indicator of some sort in or near the URL bar, and this indicator might as well provide the means for switching the mode as well.

What behavior would we want in “normal mode”? Pages that get viewed are eligible for sharing, but only if that page is determined to be a “public” page (see other essays for details on this). So the plugin would need to capture the content of the page and immediately after rendering it (perhaps in a separate thread) begin to process it for possible sharing. I’ve used the term “page”, but essentially all content should be treated this way, including images, CSS and JavaScript files, even AJAX calls: any content downloaded by the browser.

The next question is when content should be downloaded from the archive. Unlike Google Web Accelerator, I think it is unlikely that this design involving anonymous P2P technology will ever be faster than ordinary browsing to a normally functioning web site. But it can be available in those cases where the ordinary site no longer is, where the HTTP request times out, or a 404 (page not found), 410 (page gone), 503 (server overloaded) or some other error is returned. The simplest solution would be to attempt to load the page from the storage network whenever these conditions occur. Always trying to load every page from both web and storage (and displaying the one that arrives first) would put far too much load on the storage network for pages that would never be viewed.

It is worth noting that this storage network can store multiple versions of each page. This could be because the page has changed over time, because it is served up differently to different classes of user (perhaps by geographic region), or for stranger reasons like a malicious user injecting false versions of a page into the network. This property might lead to some very interesting and powerful uses (“See old versions of any page!”) and it might pose new technical challenges (“Allow trusted entities like the EFF to somehow flag which version of the page is ‘real’”). Such considerations are an excellent subject for future consideration, but the next essay will address technical challenges with the storage and the final part will show how to anonymously determine whether to share a page.

Well, Google eventually dropped Google Web Accelerator (I wonder why?), but the idea is interesting. Suppose you wanted to build a similar tool that would capture the web viewing experience of thousands of users (or more). For users it could provide a reliable source for sites that go down or that get hit with the “slashdot” effect. For the Internet Archive or someone a smaller search engine like Duck Duck Go, it would provide a means of performing a massive web crawl. For someone like the EFF or human-rights groups it would provide a way to monitor whether some users (such as those in China) are being “secretly” served different content. But unlike Google Web Accelerator, a community-driven project would have to solve one very hard problem: how do this while keeping the user’s browsing history secret — the exact opposite of what Google’s project did.

This topic came up at a meeting of the Philly Startup Hackers group, and after an entire evening of vigorous discussion, we think that such a project would be technically feasible. In this series of essays I will attempt to outline the technical architecture of this solution. This first one will explain the major components and how they fit together.

Broadly, I’ll describe three different problems to be solved and we’ll assume that the solution to each one is a layer in the architecture. Problem (A) is the user interface, problem (B) is deciding what information is public (surprisingly, this turns out to be the most difficult part), and problem (C) is storing the pages.

The solution to problem (A) (user interface) is quite straightforward. That is not to minimize it: implementing the user interface well is by far the most work of the whole project and the piece most likely to contribute to the success or failure of it. But the approach to take is clear. This should integrate into the customer’s browser, and with modern browsers that means implementing it as a browser plug-in. Also essential to the user experience is the installation experience: to be successful, this needs to be extremely easy to install and very simple to configure (preferably with no configuration required for use).

Problem B is to decide what pages should be public, and which are private to the user. The UI can help here if users can easily flip into modes where everything is captured or where nothing is. But one cannot expect the user to click something before (or after) every page — there also needs to be a “normal” browsing mode. We’d like to (anonymously) record the majority of pages visited (after all, that’s the point of the tool), but a page showing your bank account probably shouldn’t be shown, nor should a Google Docs essay you’ve been writing. Assuming that everything viewed with HTTPS is private and everything viewed with HTTP is public seems much too simple a rule, particularly as privacy sensitive sites are beginning to default to HTTPS for all users.

So the approach I am proposing is that we assume that if several people see the exact same page then it must be a public one. My bank’s logged-in view of my accounts won’t be seen by any other users, while the Google Doc essay I share with a friend will only be seen by a couple of people. If we set the threshold to something like 6 or 9 users then we can be fairly confident that the content was public. To capture rarely-seen sites we’d want the count to last for some time: 6-9 users within the same month, perhaps. Now the technical challenge is to figure out how to tell whether several people have seen the content without revealing it (since it’s private) and without leaving any trace that we have viewed it (for privacy reasons).

Problem C is storing the content. Spotify is a popular music player which has been installed by millions of users. Yet they don’t need huge servers to transmit all those data streams. Instead, they use P2P technology and each user provides a certain amount of storage and a certain amount of bandwidth. Other projects like Freenet have proven that P2P sharing can store data and keep all the participants anonymous. So I propose leveraging fairly standard P2P approaches (or better yet, an existing P2p storage network) for storing, finding, and retrieving the content.

Well, that’s enough for one essay. Check back in part 2 for more details about the UI, part 3 for a discussion of the storage network, and part 4 for analysis of how to anonymously determine whether something can be shared.

If you ever see “Host error number XXX”, it means that this was the XXX’th error of the day that this Profile instance wrote to the logs. Get someone to look it up in the Profile logs.

Also, Calling mrpc ZWRAP with [925, 8864, ""44758220"", |!|] will fail if 8864 is not a valid profile userid (which is the case for me).

1. Launch PowerPoint (these instructions work for Office 2010).
2. Open the presentation to be fixed.
3. Go to the File menu, and select “Options”.
4. Select “Customize Ribbon”.
5. On the right-hand side of the complex dialog find the “Main Tabs” section. Check the checkbox next to the “Developer” tab.
6. Click “OK” and return. You should now have a “Developer” menu above the ribbon.
7. Select the “Developer” menu to display the developer ribbon.
8. On the ribbon, click the button labeled “Visual Basic”
9. In the upper-left-hand side of the screen there is something labeled “VBAProject” with sub-folders labeled “Modules” some of which have entries with names like “Module1″. You may have to expand the tree-view widget to see some of these.
10. For each module, double-clicking will open it. Those that are completely blank (all of them in my company’s template) are useless and can clearly be deleted.
11. Delete a module by closing it (if you had opened it), then right-clicking on the module and selecting “Remove Module1…”. It will offer to save, but you won’t need to do that.
12. After doing this for all unwanted modules, go to the “File” menu and select “Close and Return to Microsoft PowerPoint”.
13. Save your newly-changed document.

By the way, in case anyone couldn’t tell, after experience with it I really hate Microsoft’s “ribbon”. The old approach “Menus” required people to look around through lots of menus to find the commands they needed (although if they used a command frequently, they could read the menu to see what keyboard command would execute that). Power users could modify the menus if they wanted to (but hardly anyone did). In the new “Ribbon” interface, the commands that people use a lot are just one click away — as long as you know what arcane icon represents the action that you want to perform. If you need to find a new command you no longer have to look through the menus to find it… instead you simply perform a web search to find someone else who ran that command and follow the arcane set of clicks that they wrote in order to locate the mysterious and well-hidden button that performs the action. Power-users are people who know how to perform an action without looking it up on the web.

By the way, what’s the conversion rate on really small amounts? Because of rounding, if you withdraw 1 US cent, converted to euros, they would owe you 3/4 of a euro cent, and rounded to the nearest cent that would be 1 euro cent.

So you walk into the bank and deposit $10. You then tell the teller you would like to make a 1-euro-cent withdrawal. You pocket the euro cent and your balance is $9.99. Ask for another euro cent and your balance is $9.98. Keep going and eventually you’ll have 10.00 € (in euro pennies). Now deposit this and they’ll give you $12.50. You just made $2.50. Stand there all day repeating this and you could make some real money.

Of course, this would never work. The teller might smile and give you the first euro cent, but by the second or third she’ll know that something is up. She may not figure out your currency scheme instantly (although probably she will), but she’ll tell you to get out and stop wasting her time. But if you were working with a computer instead of a cashier, then it just might work!

The interesting thing to note here is that humans and computers have very different failure modes. There are some kinds of tricks that humans fall for easily, like those that involve distraction or appeal to authority. Whereas computers won’t fall for any trick they’ve been programmed to defend against, but if you find something they are not programmed to expect, then you can exploit it over and over.

That is why robust security mechanisms combine both computers and humans, to get the best of both worlds. Usually this means that the computers do the transaction (it’s cheaper to offer online deposits and withdrawals than it is to pay a teller to work in a branch on every street corner), but you don’t just rely on the computers to keep things legit. You also have a security team who monitor the transactions and look for anything out of the ordinary. They then investigate — usually it’s just a coincidence or an unusual day, but sometimes it is an attempt at fraud or two friends who made a bet about who could generate the longest bank statement for the month of July. Then the security department can step in.

To put it succinctly and steal a bit from Lincoln: Some of the time you can fool computers all of the time. You can fool all humans but only some of the time. Fooling both is much harder.

InputStream does not represent a valid SOAP 1.1 Message

check the namespace of the SOAP envelope

SOAP 1.1: http://schemas.xmlsoap.org/soap/envelope/

SOAP 1.2: http://www.w3.org/2003/05/soap-envelope/

What I found most interesting was something that David Pollak (the post’s author) alluded to but did not emphasize: an example of a language that has solved this problem. Surprisingly, it is the much-maligned Java. (And perhaps this feature is one of the reasons for Java’s success in “the enterprise”, where backward compatibility to old or unmaintained libraries is often a very big deal.) The Java solution is to provide an incredibly strong amount of backward compatibility at the binary level (not just the source). As far as I know, essentially all code written under Java 1.0 (16 years ago) will still compile under the most recent Java release, and code compiled by that Java 1.0 compiler will still run under the most recent JVM. The price paid is some real ugliness in the name of backward compatibility like old APIs that still return Hashtable or ArrayList instead of Map or List, and type erasure that makes typed collection less powerful than they could be). But however much you may scoff at Java for poor language design, this feat of backward compatibility is something quite impressive.

My endorsements in Bold.

Retention of Judge, Pennsylvania Supreme Court (retain or not):

J. Michael Eakin

NO, do not retain! — In 2006, The PA State Legislature voted itself a pay raise in direct violation of the plain wording of the state constitution which states. Judge Eakin was one of the Supreme Court judges who found this to be constitutional. In my mind, this makes him unfit for office, and I will vote NOT to retain him.

Pennsylvania Superior Court Judge (vote for 1):

David Wecht (D)

• http://www.wecht2011.com/
• “Highly Recommended” by PA Bar association
• Lots of academic and scholarly law work

Vic Stabile (R)

• http://www.stabileforjudge.com/about.php
• Former deputy attorney general; former judicial clerk
• “Recommended” by PA Bar association

Better qualified in several ways, I endorse David Wecht.

Retention of Judge, Pennsylvania Superior Court (retain or not):

Mary Jane Bowes

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

John T. Bender

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Pennsylvania Commonwealth Court Judge (vote for 1):

Anne Covey (R)

• http://www.coveyforjudge.com/
• Bar says “Recommended”

Kathryn Boockvar (D)

• http://www.boockvar.com/
• Bar says “Recommended”

Everything I could read paints both as decent, qualified candidates. I may cast my own vote based on party endorsement, but I cannot independently endorse either candidate.

Retention of Judge, Pennsylvania Commonwealth Court (retain or not):

Robert E. Simpson, Jr.

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Renee Cohn Jubelirer

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Mary Hannah Leavitt

• http://www.pabar.org/public/news%20releases/pr092811.asp
• Bar says to keep. I have no independent background knowledge, so I will ABSTAIN.

Pennsylvania Court of Common Pleas Judge (vote for 5):

Nathaniel C. Nichols (R,D)

• Endorsed by both major parties, that’s good enough for me!

Christine Fizzano Cannon (R,D)

• Endorsed by both major parties, that’s good enough for me!

G. Lawrence Demarco (D)

Sally Ann Heckert Bikin (D)

Michael F. Schleigh (D)

Spiros E. Angelos (R)

John P. Capuzzi, Sr. (R)

G. Michael Green (R)

By the time I had reached these, I had run out of energy to do my research. I really don’t know much about them and so I can’t make any recommendations except to vote for the two who were endorsed by both parties.

Delaware County Council Member (vote for 3):

Jayne Young (D)

• http://haverford.patch.com/info_page/council-member-candidate-jayne-young
• Background: Mayor of Landsdowne
• Came to speak on non-discrimination bill in Haverford.
• Issues: economic revitalization. Health department. Visit each municipal council. Transparent government.

John McBlain (R)

• http://haverford.patch.com/info_page/council-member-candidate-john-mcblain
• Background: City solicitor
• Issues: Job creation via property tax abatement for new development

Lin Axamethy Floyd (D)

• http://haverford.patch.com/info_page/h-questions-council-member-candidate-lin-axamethy-floyd
• Background: Habitat for Humanity & others. DuPont
• Issues: transparent government

Keith Collins (D)

• http://haverford.patch.com/info_page/patch-questions-council-member-candidate-keith-collins
• Background: Army, Police, Minister, Community College Prof
• Issues: transparent government

Thomas McGarrigle (R)

• http://haverford.patch.com/info_page/council-member-candidate-tom-mcgarrigle
• Issues: Economic Biz Development

Colleen P. Morrone (R)

• http://haverford.patch.com/info_page/council-member-candidate-colleen-morrone
• Works at Goodwill
• Economic Biz Development

I have seen Jayne Young “in action” and I was impressed. She was fair, articulate, and wise. I endorse her. The others I know much less about. Based on a combination of biography/background and issues, I am happy to support Lin Floyd, Keith Collins, and Colleen Morrone — and that’s one more than I’m allowed to vote for.

Delaware County District Attorney (vote for 1):

Jack Whelan (R)

• http://jackwhelan4da.com/
• Background: County Council Chair, Assistant DA

M. Kendall Brown (D)

• http://www.kendallbrownforda.com/
• Background: Lawyer, Victims Rights Organizer

Kendall Brown is simply not as well qualified for the post. She does not hold an active law license at the moment (says it’s a paperwork issue and will be sorted out). Meanwhile, Jack Whelan is competent and qualified. This endorsement of Jack Whelan is from the Delaware county democrats.

Haverford Township School Director, “School Board” (vote for 5):

Lawrence A. Feinberg (R,D)
Maxine Murdoch (R,D)
Joseph P. Martin (R,D)
Coleen Bennett (R,D)
Patricia Giambuzzi (R,D)

We have a tradition in our township of non-partisan school board elections. All 5 candidates running are excellent, and I endorse them all. Larry Feinberg in particular has done an excellent job and I believe he will continue to do so.