[cc-devel] protocol relative/https urls on Creative Commons pages

[Maarten Zeinstra]

Hi all,

I use the HTTPS everywhere plugin for Chrome and that messes up some of the CreativeCommons.org pages. Chrome doesn't allow loading .js and .css files from HTTP links within HTTPS pages anymore. This severely messes up pages like all legalcode pages and the namespace page.

I already discussed this with Nathan Kinkade, but he indicated that he will not have time to work on it and it seems to be something that is possibly only the case in the newest Chrome browser a problem. Chrome doesn't seem to try to resolve those links in https.

However I think that more browser will follow Chrome's lead in this and that we should (re)work these pages to either be protocol relative or force https.

Would we agree?

Cheers,

Maarten

[Jonas Öberg]

Hi Maarten,

I don't see why this shouldn't be protocol relative.
What is needed to be done to revise this?

Sincerely,
Jonas

Post by Maarten Zeinstra
Hi all,
I use the HTTPS everywhere plugin for Chrome and that messes up some of
the CreativeCommons.org pages. Chrome doesn't allow loading .js and .css
files from HTTP links within HTTPS pages anymore. This severely messes up
pages like all legalcode pages and the namespace page.
I already discussed this with Nathan Kinkade, but he indicated that he
will not have time to work on it and it seems to be something that is
possibly only the case in the newest Chrome browser a problem. Chrome
doesn't seem to try to resolve those links in https.
However I think that more browser will follow Chrome's lead in this and
that we should (re)work these pages to either be protocol relative or force
https.
Would we agree?
Cheers,
Maarten
--
Kennisland *
*
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130624/bb7f9c48/attachment-0001.html

[Maarten Zeinstra]

Refactor all links from a form like

http://www.creat..

to

//www.creat?

I don't know if that notation is backward compatible with most browsers though.
--

Post by Jonas Öberg
Hi Maarten,
I don't see why this shouldn't be protocol relative.
What is needed to be done to revise this?
Sincerely,
Jonas
Hi all,
I use the HTTPS everywhere plugin for Chrome and that messes up some of the CreativeCommons.org pages. Chrome doesn't allow loading .js and .css files from HTTP links within HTTPS pages anymore. This severely messes up pages like all legalcode pages and the namespace page.
I already discussed this with Nathan Kinkade, but he indicated that he will not have time to work on it and it seems to be something that is possibly only the case in the newest Chrome browser a problem. Chrome doesn't seem to try to resolve those links in https.
However I think that more browser will follow Chrome's lead in this and that we should (re)work these pages to either be protocol relative or force https.
Would we agree?
Cheers,
Maarten
--
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130624/cadd4497/attachment.html

[Jonas Öberg]

I was poking around on http://code.creativecommons.org/viewgit/ to see if I
could find where the actual templates are that introduce those links, but I
couldn't find them. Is there an overview of the different repositories
anywhere? (I saw the deeds in cc.engine, but not the licenses itself).

Sincerely,
Jonas

Post by Maarten Zeinstra
Refactor all links from a form like
http://www.creat..
to
//www.creat?
I don't know if that notation is backward compatible with most browsers though.
*
*
*
--
Kennisland
*
Hi Maarten,
I don't see why this shouldn't be protocol relative.
What is needed to be done to revise this?
Sincerely,
Jonas

Post by Maarten Zeinstra
Hi all,
I use the HTTPS everywhere plugin for Chrome and that messes up some
of the CreativeCommons.org <http://creativecommons.org/> pages. Chrome
doesn't allow loading .js and .css files from HTTP links within HTTPS pages
anymore. This severely messes up pages like all legalcode pages and the
namespace page.
I already discussed this with Nathan Kinkade, but he indicated that he
will not have time to work on it and it seems to be something that is
possibly only the case in the newest Chrome browser a problem. Chrome
doesn't seem to try to resolve those links in https.
However I think that more browser will follow Chrome's lead in this and
that we should (re)work these pages to either be protocol relative or force
https.
Would we agree?
Cheers,
Maarten
--
Kennisland *
*
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130624/333ac467/attachment.html

[Nathan Yergler]

I don't remember which repo those were stored in. There used to be a
poorly maintained list of repositories in the wiki, but I suspect
that's been culled (since it was usually incomplete).

Keep in mind those legalcode pages are static and the organizational
commitment is to *not* change them once they're published.

NRY

Post by Jonas Öberg
I was poking around on http://code.creativecommons.org/viewgit/ to see if I
could find where the actual templates are that introduce those links, but I
couldn't find them. Is there an overview of the different repositories
anywhere? (I saw the deeds in cc.engine, but not the licenses itself).
Sincerely,
Jonas

Post by Maarten Zeinstra
Refactor all links from a form like
http://www.creat..
to
//www.creat?
I don't know if that notation is backward compatible with most browsers though.
--
Kennisland
Hi Maarten,
I don't see why this shouldn't be protocol relative.
What is needed to be done to revise this?
Sincerely,
Jonas

Post by Maarten Zeinstra
Hi all,
I use the HTTPS everywhere plugin for Chrome and that messes up some of
the CreativeCommons.org pages. Chrome doesn't allow loading .js and .css
files from HTTP links within HTTPS pages anymore. This severely messes up
pages like all legalcode pages and the namespace page.
I already discussed this with Nathan Kinkade, but he indicated that he
will not have time to work on it and it seems to be something that is
possibly only the case in the newest Chrome browser a problem. Chrome
doesn't seem to try to resolve those links in https.
However I think that more browser will follow Chrome's lead in this and
that we should (re)work these pages to either be protocol relative or force
https.
Would we agree?
Cheers,
Maarten
--
Kennisland
_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Nathan Kinkade]

Post by Maarten Zeinstra
Refactor all links from a form like
http://www.creat..
to
//www.creat?
I don't know if that notation is backward compatible with most browsers though.

It is. We use it protocol-relative URLs in a number of places already.

Nathan

[Maarten Zeinstra]

Thanks Nathan K for clarifying that.

On Nathan Y's remark on changes to the legalcode-pages. I don't think that making them more secure (i.e. more accessible for people who browse the web certain ways) would change anything in the legal code. We shouldn't confuse significant changes to the actual texts or appearance to the these document to keeping up to date with technology. We are actually changing the appearance of these pages by not changing them, as they won't load properly on user's browser with more strict security guidelines..

I would be we wholly in favour of refactoring all ~750 legalcode pages if that would mean that they would be accessible over more secure connections. Don't get me wrong, I believe we should never change the actual wording or layout of these documents but in 20 years these documents need still be visible to the common browser and protocols at that time. If we can now identify a trend of more https (or spdy) traffic than I think we should enable and add those protocols to these pages.

@Dan, as this will be under your supervision in a couple of weeks, what are your thoughts?

Cheers,

Maarten
--

Post by Nathan Kinkade

Post by Maarten Zeinstra
Refactor all links from a form like
http://www.creat..
to
//www.creat?
I don't know if that notation is backward compatible with most browsers though.

It is. We use it protocol-relative URLs in a number of places already.
Nathan

[Nathan Kinkade]

Diane is on this list and can weight in if necessary, but I believe
that it was lately established (at least informally so) that such
changes would be acceptable, since it only modifies the underlying
markup and not the actual license in any way.

Nathan

Post by Maarten Zeinstra
Thanks Nathan K for clarifying that.
On Nathan Y's remark on changes to the legalcode-pages. I don't think that making them more secure (i.e. more accessible for people who browse the web certain ways) would change anything in the legal code. We shouldn't confuse significant changes to the actual texts or appearance to the these document to keeping up to date with technology. We are actually changing the appearance of these pages by not changing them, as they won't load properly on user's browser with more strict security guidelines..
I would be we wholly in favour of refactoring all ~750 legalcode pages if that would mean that they would be accessible over more secure connections. Don't get me wrong, I believe we should never change the actual wording or layout of these documents but in 20 years these documents need still be visible to the common browser and protocols at that time. If we can now identify a trend of more https (or spdy) traffic than I think we should enable and add those protocols to these pages.
@Dan, as this will be under your supervision in a couple of weeks, what are your thoughts?
Cheers,
Maarten
--

Post by Nathan Kinkade

Post by Maarten Zeinstra
Refactor all links from a form like
http://www.creat..
to
//www.creat?
I don't know if that notation is backward compatible with most browsers though.

It is. We use it protocol-relative URLs in a number of places already.
Nathan

[Kat Walsh]

Nathan K's summary is a fair statement of where we are--after some
consultation we drew out the boundaries of what elements of the page
are and are not legal code that cannot be changed, and determined that
markup changes that do not modify the actual license are allowable. We
haven't yet set this down in a formal policy but will in the near
future.

-Kat

On Mon, Jun 24, 2013 at 12:24 PM, Nathan Kinkade

Post by Nathan Kinkade
Diane is on this list and can weight in if necessary, but I believe
that it was lately established (at least informally so) that such
changes would be acceptable, since it only modifies the underlying
markup and not the actual license in any way.
Nathan

Post by Maarten Zeinstra
Thanks Nathan K for clarifying that.
On Nathan Y's remark on changes to the legalcode-pages. I don't think that making them more secure (i.e. more accessible for people who browse the web certain ways) would change anything in the legal code. We shouldn't confuse significant changes to the actual texts or appearance to the these document to keeping up to date with technology. We are actually changing the appearance of these pages by not changing them, as they won't load properly on user's browser with more strict security guidelines..
I would be we wholly in favour of refactoring all ~750 legalcode pages if that would mean that they would be accessible over more secure connections. Don't get me wrong, I believe we should never change the actual wording or layout of these documents but in 20 years these documents need still be visible to the common browser and protocols at that time. If we can now identify a trend of more https (or spdy) traffic than I think we should enable and add those protocols to these pages.
@Dan, as this will be under your supervision in a couple of weeks, what are your thoughts?
Cheers,
Maarten
--

Post by Nathan Kinkade

Post by Maarten Zeinstra
Refactor all links from a form like
http://www.creat..
to
//www.creat?
I don't know if that notation is backward compatible with most browsers though.

It is. We use it protocol-relative URLs in a number of places already.
Nathan

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/cc-devel

[Dan Mills]

Hey all,

Good discussion.

After my prodding earlier about separating the licenses from the way the licenses are marked up, styled, and presented, Kat has been leading a discussion on the affiliates list about establishing what exactly is OK to change (in principle) and what isn't.

IMO, protocol-relative URLs are a good example of a case where we should change the license files. However, we need:

1) a solid understanding of where the boundaries are (discussion Kat is leading), and
2) a clear process that ensures the licenses don't change in the legal sense when we make those changes.

Ideally we would also have some technical safeguards to make this less risky (such as scripts that take minimally marked up license text and output the licenses for presentation), but we can make do with human checks in (2) instead.

Dan

Post by Nathan Kinkade
Diane is on this list and can weight in if necessary, but I believe
that it was lately established (at least informally so) that such
changes would be acceptable, since it only modifies the underlying
markup and not the actual license in any way.
Nathan

Post by Maarten Zeinstra
Thanks Nathan K for clarifying that.
On Nathan Y's remark on changes to the legalcode-pages. I don't think that making them more secure (i.e. more accessible for people who browse the web certain ways) would change anything in the legal code. We shouldn't confuse significant changes to the actual texts or appearance to the these document to keeping up to date with technology. We are actually changing the appearance of these pages by not changing them, as they won't load properly on user's browser with more strict security guidelines..
I would be we wholly in favour of refactoring all ~750 legalcode pages if that would mean that they would be accessible over more secure connections. Don't get me wrong, I believe we should never change the actual wording or layout of these documents but in 20 years these documents need still be visible to the common browser and protocols at that time. If we can now identify a trend of more https (or spdy) traffic than I think we should enable and add those protocols to these pages.
@Dan, as this will be under your supervision in a couple of weeks, what are your thoughts?
Cheers,
Maarten
--

Post by Maarten Zeinstra
Refactor all links from a form like
http://www.creat..
to
//www.creat (http://www.creat)?
I don't know if that notation is backward compatible with most browsers though.

It is. We use it protocol-relative URLs in a number of places already.
Nathan

_______________________________________________
cc-devel mailing list
cc-devel at lists.ibiblio.org (mailto:cc-devel at lists.ibiblio.org)
http://lists.ibiblio.org/mailman/listinfo/cc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/cc-devel/attachments/20130624/12be1531/attachment.html