One
===
This incident is a specific case, involving applicants to BS (biz school) programs, that restrict entry/participation, in said programs, based, in part, on an *application process*. Historically, most of these applications processes *intentionally* have opaque and transparent components, as far as applicants are concerned.

So, what are the stated terms and conditions of the various BS applications processes that were managed/implemented by ApplyYourself? What about the process is agreed upon as being transparent and what will remain opaque to applicants?

And what are the stated terms and conditions for applicants to verify the accuracy, completeness and security of their personal information as provided in their applications?

...

Curiosity about one's own "personal infomation" as provided to, processed and digitally stored by an applications processing entities could have and should have been expressed in the form of a formal inquiry, directed to the Information Privacy and Security Compliance Offers at ApplyYourself and the respespective BS-es. This inquiry requires no act of tresspass or unsanctioned access to "non-public" systems/information.

Curiosity about one's own status within a developing application process, is a very different matter.

If there are explicit rules governing the time-sensitive, staged release of certain applicatons status information, back to individual applicants, then those rules must be adhered to, at risk of whatever the stated consequences are for any non-compliance. But, certainly, not all information about applications processes can be expected to be disclosed, too. Some of it remains confidential.

Curiosity, inquiries and/or concern about the accuracy, completeness and security of one's own personal information as stored by another is not the same thing as gaming a process/system that uses said information.

Manipulating a system, in an attempt to expose that which has been agreed to, in advance, as being otherwise opaque is not ethical conduct.


Two
===
The Internet is a public space.

In all of the mad rush to put everything imaginable on the public Internet, the onus has got to be on the implementor/proprietor to exercise great attention and care to any need for privacy and security when electing to use the Internet in any part of any process. Designs and implementations must be correct, thorough and sufficient, precisely because the Internet IS public AND there are other ways and means of accomplishing the same work-processes without involving the Internet.

If one makes the choice to entice others into participating in an otherwise non-public process, using the Internet as a medium, then the enticer has got to take care of guaranteeing and protecting whatever is explicitly private and intented to be non-public from unauthorized exploitation via the Internet.

[ This is a major point of *shirked responsibility* (and, ultimately, liability) on the part of the vast majority of financial institutions, that are actively luring consumers and business customers into partaking of Internet mediated "financial services." Most of these service agreements/contracts attempt, as buried in fine print verbage, to completely indemnify the financial institution from responsibility for losses to consumers/customers stemming from computer and Internet compromises. ]

So, ApplyYourself, and every participating BS, must be held to a high standard of care with regard to all of their Internet-mediated but otherwise proprietary and private processes.


Three
=====
Let's not mince words... All URLs are "scripts" to standard Internet browsers and a script could be a heavily encoded URL.

If ApplyYourself and/or any BS is going to permit the use of a standard Internet browser as the authorized access client to their Internet-mediated applications processes, then ApplyYourself and said BS-es must fully meet the burden of securing their processes, and all private data, against threats posed by hte Internet, including manually retyped URLs.

Manually retyped URLs are forms of "free speech" and manually retyped URLs have to be expected/anticipated with the use of any standard Internet browser as authorized client.

If a website responds "inappropriately" to inappropriate speech from a standard Internet browser, then it is the fault of the makers, endorsers and proprietors of that web site/web interface.

One way around this could be to provide and require (administratively and progrmamatically) the use of a completely proprietary (as in non-HTML/non-XML/non-X-script/non-standards using), secured access client to it's web interface. Then, trying to retype or originate wild variations on client-server communications would not be so easily construed as being "free speech." It would be closer to some deliberate, non-casual and overt act of reverse re-engineering an intentionally proprietary system.


Four
====
In this case, there are simply too problems to be found all the way around. Almost all are of the low-hanging fruit variety.

Shame on One And All in this mess...

That is why I agree more with Stanford's approach than with Harvard's.

Stanford's conditional review implicitly accepts partial responsibility for having participated in the creation of a public nuisance.

Harvard's hard-line absolves itself of any responsibility.

Perhaps, the most shame should fall to the chowder-heads @ApplyYourself.



[ reply ]

Link to this comment: http://www.securityfocus.com/comments/columns/309/31170#31170