127038 - Clearly identify external links

Status: ASSIGNED

(SeaMonkey :: UI Design, defect)

Description

[Ben Bucksch (:BenB)]

Clearly and obviously showing that a link is external or internal is a
requirement in German law. If the UA does not provide that information, sites
have to implement it manually. This is tiresome and runs against the spirit of
HTML (rich semantical, machine-interpretable information, allowing the UA to
fully control the presentation).

This should be fixed ASAP IMO. If we don't (and Microsoft doesn't), we'll be
forever stuck with little icons before links or other content that the UA could
have infered from the markup.

Apart from that, I think that this is highly useful for users.


Implementation suggestions:
External = different server. Maybe also different scheme (http vs ftp).
Display: (alternatives, non-exclusive)
- Add an icon before the link, if the link is external.
- Otherwise display the link differently (other color, some text decoration)
- Add "External: <server>" in a separate line to tooltip.
- Slashdot-style: Add text [<server>] after the link text (I don't like this
  one).

Assigning to mpt for UI input.


References:
German law
<quote src="http://www.netlaw.de/gesetze/tddsg.htm">
Gesetz über den Datenschutz bei Telediensten
(Teledienstedatenschutzgesetz -TDDSG)
{...]
§ 4
Datenschutzrechtliche Pflichten des Diensteanbieters
[...]
(3) Die Weitervermittlung zu einem anderen Diensteanbieter ist dem Nutzer
anzuzeigen.
</quote>

My translation:
Law about the privacy in communication services.[...]
Privacy obligations of the service provider[...]
The forwarding to another serivce provider has to be indicated to the user

It is likely that the European Union has similar "guidelines", meaning that most
European countries have similar legislation.

Law interpretation:
I will attach the guidelines for websites from the (official) Hamburg privacy
commisary (in German), because it's too long.
He has realisation guideline, which might give hints for us:
* Mentioning the provider of the link target in the text or describing the
  link as external.
* Link tooltip mentioning provider of link target.
* Offers from different companies within a company group are considered
  external.
* Not sufficient is a general disclaimer that the site contains external links.

W3C UUAG:
<quote src="http://www.w3.org/TR/2001/CR-UAAG10-20010912/guidelines#tech-info-link">
1. To help the user decide whether to traverse a link, make available the
following information about it:
[...]
* whether the link is internal to the resource (e.g., the link is to a target in
the same Web page),
</quote>

Comment 1

[Ben Bucksch (:BenB)]

Attachment: Hamburg privacy commisary - Guidelines for external links on websites (German)

Comment 2

[Ben Bucksch (:BenB)]

> * whether the link is internal to the resource (e.g., the link is to a target
> in the same Web page),

ops, I misread that (page->site). Still, the German law requirements apply.


I personally don't think that a toolip is sufficient. I'd prefer a little image.

We have to figure out, how to mark external links that are represented by images
only. (<a href=""><img src="" border=0></a>). If we used images to mark external
links, we could overlay it over one edge of the image, assuming it's large enough.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This should be completely under the control of the user, btw.  As in, there
should be a pref to turn this the hell off.

Comment 4

[Ben Bucksch (:BenB)]

of course.

Comment 5

[Matthew T (active 1999-2002)]

To dispose of a minor detail first, this isn't an accessibility bug, as Ben
realized in comment 2. Indicating whether a link goes elsewhere on the same page
is bug 58135. Removing access keyword.

Now for identifying external links. There are three broad reasons why this bug
is a wontfix. (1) It's only necessary for a small minority of sites on the Web,
while being detrimental to the rest. (2) Implementing it in Mozilla wouldn't
save those sites any effort, because they'd still have to do the distinguishing
themselves anyway. (3) We couldn't possibly distinguish between `internal' and
`external' links even if we wanted to.

(1) As far as I can tell from the translation, this requirement applies only to
German `service providers', maybe German companies in general, and possibly EU
companies in general. Even with the most optimistic guess (EU companies in
general), that's still a tiny minority of Web sites. For almost every other Web
site it would be a pain in the proverbial -- visually penalizing Web authors for
linking outside their own site, despite the Web as a whole being better off when
there are *more* such external links.

(2) The requirement is on the service providers, not on the browsers which
render the sites of those service providers. To say that Mozilla is not the only
browser in the world is a severe understatement, and as long as there are
browsers which don't try to make such distinctions, those sites will need to
roll their own distinguishing marks anyway.

(3) This couldn't be implemented even if we wanted to, because a computer
program can't possibly determine whether two pages are on the same `site'. How
is a program to realize that:
*   <http://microsoft.com/windows/> and <http://windowsupdate.com/> are part of
    the same site (as indeed they are -- windowsupdate.com is a mirror of
    windowsupdate.microsoft.com), but <http://microsoft.com/windows/> and
    <http://winsupersite.com/> are different sites?
*   <http://mozilla.org/releases/> and <http://mozilla.org/docs/> are part of
    the same site, but <http://geocities.com/fakulti/> and
    <http://geocities.com/swimp44139/> are different sites?
*   <http://apple.slashdot.org/> and <http://ask.slashdot.org/> are part of the
    same site, but <http://aps.school.nz/> and <http://waimea.school.nz/> are
    different sites?
The only semi-reliable method of telling whether two pages are part of the same
site is if the authors of both pages tell you so -- that is, if they have a
<link rel="home"/> element with the same href. And it's highly unlikely that
such links are ever going to be provided on the majority of Web pages.

Comment 6

[Ben Bucksch (:BenB)]

> EU companies in general [is] a tiny minority of Web sites

huh? You are aware that the EU is as large as the US, right?

> For almost every other Web site it would be a pain in the proverbial --
> visually penalizing Web authors for linking outside their own site,

uh, no. The goal is not to penalize at all. But a user should be aware when he
changes the providing entity, just as I should be aware when my favorite
magazine is now run by another company. It's very similar to showing the link
URL in the status bar. But the attempt of the regulators shows that the status
bar doesn't fulfill the job - something more obvious is needed. That's all that
I'm trying to achieve.

> as long as there are
> browsers which don't try to make such distinctions, those sites will need to
> roll their own distinguishing marks anyway.

I want to demonstrate and convince that identifying external sites is not the
job of the site, but the browser. (For the reasons stated above.) An
implementation in a well-known browser might change the mind of the
(well-intended, but wrong-heading) regulators, saving that part of HTML.

> a computer program can't possibly determine whether two pages are on the
> same `site'.

It can. It's a well-understood problem. There are lots of places (not visible to
the user), where we do that already, for example in JavaScript priviledges (when
determining, if the script is allowed to access the content of the other
window/frame) or cookie code (foreign cookies disallowed).

The accepted solution is to match for the same host. It is not perfect, but
works in the important cases.

REOPENing, assinging to myself.

Comment 7

[Ben Bucksch (:BenB)]

.

Comment 8

[Boris Zbarsky [:bzbarsky]]

> The accepted solution is to match for the same host. It is not perfect, but
> works in the important cases.

Sure, as long as you only care about big sites and as long as you're willing to
accept "false positives" (which we _are_ in the security case).

However, our legal position would be fairly untenable, imo, if we implemented
that solution and then claimed to comply with the law you cite.  It would be
trivial to find examples where we fail in one way or the other and the claim of
compliance in this case may well leave us open to legal action (in the US it
certainly would in that situation).

A legal expert familiar with German and maybe EU law should be consulted on this
bug, again imo.

Comment 9

[Aaron Leventhal]

The W3C thinks that this relates to accessibility:
http://www.w3.org/TR/2001/CR-UAAG10-20010912/guidelines#tech-info-link

Comment 10

[Boris Zbarsky [:bzbarsky]]

That applies to links to a different _page_ not links to a different _site_,
which are what this bug is about.  Hence mpt's comments about comment #2 on this
bug...

Sure, we can put a little flag next to any link that's not a link to a named
anchor (which is what the W3C suggests).  That will not fix this bug at all (but
yes, we should do it, imo).

Comment 11

[Aaron Leventhal]

I stand corrected, the W3C UAAG says nothing about this. The working group
decided only to require indicating when a link goes outside the current page
(not site).

Comment 12

[Matthew T (active 1999-2002)]

For the benefit of reviewers/super-reviewers if/when the time comes: I think any
implementation of this RFE would make Mozilla worse rather than better
(*especially* if there was a pref for it), and make the Web worse (in proportion
to Mozilla's market share) as well. I'm done here.

Comment 13

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420