[Imc-web] Re: [IMC-Tech] Adding Tags to Articles
Barry Isralewitz
barryi at ks.uiuc.edu
Mon Jun 11 14:18:15 CDT 2007
Hello,
On Jun 10, 2007, at 5:38 PM, Mike Lehman wrote:
> Thanks for confirming that it wasn't you, David.
>
> We need to have whoever did this take responsibility for it.
>
> Then we need to have any such changes to the website approved by
> consensus on list here, at a minimum.
>
> Otherwise, we have a significant security problem that we need to
> get to the bottom of ASAP. This is very inappropriate and if we
> need to start over with a complete review of who has site and
> server permissions to get to the bottom of it, then that's what
> we'll need to do. It would be good to get this resolved, otherwise
> we're going to need to have all the Tech people to the next
> Steering meeting to make sure that we're all on the same page -- or
> simply turn things off until we get that consensus established.
> Otherwise, we have a significant security problem that we need to
> get to the bottom of ASAP. This is very inappropriate and if we
> need to start over with a complete review of who has site and
> server permissions to get to the bottom of it, then that's what
> we'll need to do. It would be good to get this resolved, otherwise
> we're going to need to have all the Tech people to the next
> Steering meeting to make sure that we're all on the same page -- or
> simply turn things off until we get that consensus established.
Don't know a thing about how you guys are doing web admin, but do I
understand correctly that: It is somehow not immediately clear to
your web administrators which human made changes to your web site?
If so:
There seem to be lots of approaches to engineering in
accountability here, starting with a rule that users in the web admin
group must always make changes with an account accessible only to
them. Then, anyone who makes changes by su-ing to a more anonymous,
non-single-human admin account (www??) is taking a non-accidental --
even semi-hostile -- action; and a pointless one, since the su logs
will associate these changes with a specific-human's account anyway.
For more serious control, is there a reason you can't take the
Subversion revision control approach?
I'm about to start multiple-user web admin on thebikeproject.org. I
was looking into using
Subversion with some added Perl modules (SVN::Notify::Mirror) which
enable a simple post-commit script which can do this simple, useful
trick: transfer changes -- tested on a non-public test site -- to
a public-version production web site, _automatically_ when the web-
admin-user commits the changes. Sounds convenient and easy to work with.
Such an approach of course contains full logs and versioning, and
per-line accountability (via the "svn annotate" command, a.k.a., "svn
blame"). "Who changed file X?" is never a question.
Apologies if I'm missing something here (e.g. maybe Drupal + whatever
else you use can't be administered with versionable flat files or
something). Just responding to what sounded like a weird question,
not making any conclusions about your admin procedures...since I
don't know what they are.
Cheers,
Bary
>
> Otherwise, we have a significant security problem that we need to
> get to the bottom of ASAP. This is very inappropriate and if we
> need to start over with a complete review of who has site and
> server permissions to get to the bottom of it, then that's what
> we'll need to do. It would be good to get this resolved, otherwise
> we're going to need to have all the Tech people to the next
> Steering meeting to make sure that we're all on the same page -- or
> simply turn things off until we get that consensus established.
>
> Ever since wayward's (perhaps witting, perhaps unwitting)
> compromise of the website's privacy, I know of a number of
> registered users who won't use their accounts and prefer to remain
> anonymous, because her actions/inactions, whether intentional or
> not, have compromised what our users have come to expect. This is
> yet another incident that's suggestive of less than fully ethical
> or competent web administration on our part and we need to get this
> sorted out and the bad actors locked out before it does further
> damage.
> Mike Lehman
>
> David Gehrig wrote:
>> Mike, don't know who put them up, but it's not me.
>>
>> We've already had a problem with someone deciding to hang
>> something on UCIMC that exposed IP addresses to the public.
>> We should discuss this on Wednesday. My view is that IP
>> addresses shouldn't be exposed outside the site, and they
>> should only be exposed to the Web folks to the minimum
>> degree possible to fight spammers.
>>
>> The trade-off, of course, is that we don't want to
>> ghetto-ize ourselves either by locking ourselves out of
>> major services.
>>
>> Either way, I've changed a setting to turn off the
>> google link and not to display the logos.
>>
>> On 6/10/07, Mike Lehman <rebelmike at earthlink.net> wrote:
>>> Doing a little research, I came across these links:
>>> http://digg.com/privacy
>>> http://www.bit-tech.net/columns/2006/06/03/web_2_privacy/1
>>>
>>> del-icio.us is associated with Yahoo, which has long been
>>> infamous for
>>> its exploitation of user data through web beacons:
>>> http://del.icio.us/help/privacy
>>>
>>> technorati
>>> http://technorati.com/about/privacy.html
>>>
>>> The Google thing seems associated with the Google blog mechanism.
>>> Google
>>> has some big issues with privacy, too, and providing a direct
>>> link from
>>> an IMC seems problematic.
>>>
>>> Interesting comments on the issue as a whole:
>>> http://www.readwriteweb.com/archives/
>>> openyou_the_limits_of_privacy.php
>>>
>>> All in all, this makes the IMC site seem to look like a blog, even
>>> though we've got consensus that IMC is NOT a blog. Having these
>>> tags on
>>> the site will tend to encourage blog-type behavior, something which
>>> we've been struggling with lately, even though we've explicitly
>>> rejected blogging as part of the main news site.
>>>
>>> Note that I do not object to setting up a separate UC IMC blog,
>>> if some
>>> members feel we need it. But I think that making the IMC news
>>> page look
>>> like a blog is a mistake.
>>> Mike Lehman
>>>
>>> Mike Lehman wrote:
>>> > I see that we suddenly have a variety of Google, Digg,
>>> Technorati, etc
>>> > tags added to articles on the website. I have a several
>>> concerns about
>>> > these.
>>> >
>>> > 1. They all seem to require user registration and this will
>>> presumably
>>> > compromise the privacy of those who use them on our site.
>>> >
>>> > 2.Having them on IMC makes us a party to their marketing
>>> efforts. This
>>> > seems to be a questionable policy for an IMC to engage in.
>>> >
>>> > 3. Does the software involved in these report or log IPs in any
>>> > fashion? I presume they do, given Google record on this.
>>> >
>>> > Since most internet users can presumably use the regular Google
>>> > search, I question the need for these additions, particularly
>>> so if
>>> > they raise privacy concerns as they seem to.
>>> > Mike Lehman
>>> > _______________________________________________
>>> > IMC-Tech mailing list
>>> > IMC-Tech at lists.ucimc.org
>>> > http://lists.chambana.net/cgi-bin/listinfo/imc-tech
>>> >
>>>
>>> _______________________________________________
>>> IMC-Tech mailing list
>>> IMC-Tech at lists.ucimc.org
>>> http://lists.chambana.net/cgi-bin/listinfo/imc-tech
>>>
>> _______________________________________________
>> IMC-Tech mailing list
>> IMC-Tech at lists.ucimc.org
>> http://lists.chambana.net/cgi-bin/listinfo/imc-tech
>>
>
> _______________________________________________
> IMC-Tech mailing list
> IMC-Tech at lists.ucimc.org
> http://lists.chambana.net/cgi-bin/listinfo/imc-tech
--
Barry Isralewitz Theoretical and Computational Biophysics Group, UIUC
Beckman 3043 Office Phone: (217) 244-1612 Home Phone: (217) 337-6364
email: barryi at ks.uiuc.edu http://www.ks.uiuc.edu/~barryi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.chambana.net/mailman/archive/imc-web/attachments/20070611/fd641276/attachment.html
More information about the IMC-Web
mailing list