Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday December 15 2019, @03:53PM   Printer-friendly
from the making-it-easy-for-fake-sites dept.

Google Achieves Its Goal of Erasing the WWW Subdomain From Chrome

With the release of Chrome 79, Google completes its goal of erasing www from the browser by no longer allowing Chrome users to automatically show the www trivial subdomain in the address bar.

When Chrome 76 was released, Google decided to no longer show the www "trivial subdomain" in the address bar when visiting a web site. This means, that if you are visiting www.bleepingcomputer.com, Chrome would only show bleepingcomputer.com in the address bar...

[...] According to a Google engineer, www is considered a trivial subdomain because "this isn't information that most users need to concern themselves with in most cases".

Many users, though, felt that this was a security issue, could be confusing for users, and is technically incorrect because www.domain.com is not always the same host as domain.com.

So is this a distinction without a difference or a real issue?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2, Informative) by Anonymous Coward on Sunday December 15 2019, @11:27PM (10 children)

    by Anonymous Coward on Sunday December 15 2019, @11:27PM (#932532)

    Wrong on both parts. According to Section 5 of RFC 1738, the BNF for a url is:

    genericurl = scheme ":" schemepart

    For HTTP schemes, they are defined as:

    httpurl = "http://" hostport [ "/" hpath [ "?" search ]]
    hpath = hsegment *[ "/" hsegment ]
    hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
    search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
    hostport = host [ ":" port ]
    host = hostname | hostnumber
    hostname = *[ domainlabel "." ] toplabel
    domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
    toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
    alphadigit = alpha | digit
    hostnumber = digits "." digits "." digits "." digits
    port = digits

    You'll notice that the slash after the hostport is required only if you include a path or a query, or, as 3.3 puts it, "If neither <path> nor <searchpart> is present, the "/" may also be omitted." Which makes since because scheme normalization states that empty paths should be normalized to "/". They are literally references to the same location, and no redirects are required. In fact, a redirect from one to the other or serving different content is a violation of the RFCs for most Internet protocols, including HTTP.

    In addition, hosts are defined in 3.1 as:

    host
                    The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses.

    And none of the referenced RFCs describe the SERVICE.WHATEVER syntax you describe.

    Starting Score:    0  points
    Moderation   +2  
       Informative=2, Total=2
    Extra 'Informative' Modifier   0  

    Total Score:   2  
  • (Score: 2) by barbara hudson on Monday December 16 2019, @12:51AM (7 children)

    by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Monday December 16 2019, @12:51AM (#932573) Journal

    Read the man pages. If you're going to actually implement a server, they're the authoritative source. Not the RFCs. They don't do anything for giving actual implementation details. Where's SO_KEEPALIVE and SO_LINGER in your RFC? Nowhere. They are far from complete when it comes to actually implementing a server. Where's the description of how to open a socket? How to close it properly? Nowhere.

    Anyone can quote an RFC. Implementation in C is hard. And the C source is authoritative. Not an RFC that doesn't include any implementation details.

    Call me back when you've implemented a server in c. (not any chickenshit scripting language).

    --
    SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
    • (Score: 1, Touché) by Anonymous Coward on Monday December 16 2019, @04:35AM (5 children)

      by Anonymous Coward on Monday December 16 2019, @04:35AM (#932687)

      Since I've already passed your last hurdle. I'll address your point. The RFCs are the authoritative source, short of market capture. The whole reason for the RFC is so that the networked systems use the same rules and speak the same language. If you are trying to write a server and your response does not follow the RFC, then the client won't properly understand you. Likewise, if you have a client send a non-complaint request, the server won't follow it either. Best case scenario is that they guess correctly (e.g. see various handling of "ICY 200 OK" responses), worst case you get garbage or a cryptic socket error when they disconnect on you.

      And, by the way, implementation-specific socket options have nothing to do with that common language. You can implement a server, even an HTTP one, just fine without either SO_KEEPALIVE or SO_LINGER. You can't do it without following the protocols. The way you imagine it is that recipes should include instructions on what buttons to push to turn on your oven. But, I'll check the man page [debian.org] anyway. OH what is that? The synopsis says the slash at the start of the absolute path is optional. And no mention of your SERVICE.DOMAIN.TLD domain name setup either. And some of that BNF looks familiar. It is almost like they copied it from the RFC.

      • (Score: 2) by barbara hudson on Wednesday December 18 2019, @02:04AM (4 children)

        by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Wednesday December 18 2019, @02:04AM (#933531) Journal
        Request for comment is exactly that = a request for comment. The actual accepted implementation is the standard, because it has to go into implementation behaviour, something the RFCs by their nature cannot do. Stop being a pedant. It's almost 2020, and nobody gives a shit what the IETF says any more. (Obviously Google doesn't any more).

        There is NO requirement that everyone on the net "speak the same language." Or have you forgotten AlterNIC? Great idea that temporarily broke the monopoly on domain names. We really should bring it back.

        --
        SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
        • (Score: 0) by Anonymous Coward on Thursday December 19 2019, @08:27AM (3 children)

          by Anonymous Coward on Thursday December 19 2019, @08:27AM (#934129)

          AlterNIC was speaking the same language. They were an alternate root, but they still used the same DNS protocol as the other roots, including the Network Information Center. It literally wouldn't have worked off the shelf and been an even larger failure if it hadn't done so.

          Fact of the matter is that if the server/clients/peers don't speak the same language in the form of common standards, then they cannot communicate with each other reliably. For example, if you send, "/favicon.ico\r\n" to a web server or "GET /images/logo.png HTTP/1.0\r\n\r\n" to a gopher server, they won't understand you and give you garbage, if anything. And, as I mentioned, if not for market capture making you the de facto standard, the RFCs are as close as you'll get to that common baseline for most web related things that don't have standards elsewhere.

          Besides, your just salty that your precious man pages proved you wrong because you didn't bother to look it up.

          • (Score: 2) by barbara hudson on Thursday December 19 2019, @06:33PM (2 children)

            by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Thursday December 19 2019, @06:33PM (#934292) Journal
            But there's nothing from anyone implementing another protocol that runs over either tcp/ip or udp. Or for that matter any sort of custom datagram, as long as it has the right header info to route.
            --
            SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
            • (Score: 0) by Anonymous Coward on Thursday December 19 2019, @08:14PM (1 child)

              by Anonymous Coward on Thursday December 19 2019, @08:14PM (#934344)

              I'm not sure what you are saying. Are you claiming that HTTP is the only protocol that runs over TCP/IP (which is actually two different protocols that can be used independently) or UDP? If so, I've got news for you [wikipedia.org].

              If you are instead saying that the transport network layer doesn't really care what is carried in it in the designated place on a higher layer protocol as long as it conforms to the requirements of its own layer standard. Then yes, that is what they are designed to do, but that doesn't mean that you can arbitrarily provide all data and not meet the requirements at your level. And that doesn't mean that servers working at the application layer will magically read your mind when you don't follow the common standards for that particular protocol.

              • (Score: 2) by barbara hudson on Thursday December 19 2019, @08:42PM

                by barbara hudson (6443) <barbara.Jane.hudson@icloud.com> on Thursday December 19 2019, @08:42PM (#934356) Journal
                No, that's not what I said. Just that you can build your own protocols on top of the transport layer. As long as you write the software that understands the protocol, you don't care. As long as your client and server understand it, it matters not that any other client or server doesn't understand it. No reason why we can't build a private net atop the packet layer that doesn't need dns, or http.
                --
                SoylentNews is social media. Says so right in the slogan. Soylentnews is people, not tech.
    • (Score: 1) by Mike on Monday December 16 2019, @06:01PM

      by Mike (823) on Monday December 16 2019, @06:01PM (#932929)

      I was trying to stay out of this thread, but I'm appalled enough at the following statement that I just can't help myself.

      Read the man pages. If you're going to actually implement a server, they're the authoritative source. Not the RFCs.

      The RFC's are the specification for the protocol. Your server is the implementation. The MAN page for the server is a description of how that server works. The specification (i.e. RFC's) is authoritative. In general, when the implementation doesn't match the specification, the implementation is at fault. (occasionally, an implementation will find a problem with a specification. Then the RFC's needs to be updated/changed. Because the specification is authoritative!)

      FWIW, I haven't written any web servers. But I have created multiple implementations of multiple protocols as defined by multiple RFC's. They were mostly in C or C++, so your specs are at least partially met ).

  • (Score: 1, Redundant) by Mojibake Tengu on Monday December 16 2019, @01:05AM (1 child)

    by Mojibake Tengu (8598) on Monday December 16 2019, @01:05AM (#932582) Journal

    This syntax is incorrect. It is insufficient for hosts identified by bracketed raw ipv6 address (and port) instead of a hostname.

    --
    Respect Authorities. Know your social status. Woke responsibly.
    • (Score: 0) by Anonymous Coward on Monday December 16 2019, @03:43AM

      by Anonymous Coward on Monday December 16 2019, @03:43AM (#932672)

      I was trying to keep it simple by not putting everything, but here is the whole thing, including the updating language of 3986:

      URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
      hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-empty
      URI-reference = URI / relative-ref
      absolute-URI = scheme ":" hier-part [ "?" query ]
      relative-ref = relative-part [ "?" query ] [ "#" fragment ]
      relative-part = "//" authority path-abempty / path-absolute / path-noscheme / path-empty
      scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
      authority = [ userinfo "@" ] host [ ":" port ]
      userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
      host = IP-literal / IPv4address / reg-name
      port = *DIGIT
      IP-literal = "[" ( IPv6address / IPvFuture ) "]"
      IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
      IPv6address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3(
        h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::"
      h16 = 1*4HEXDIG
      ls32 = ( h16 ":" h16 ) / IPv4address
      IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
      dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255
      reg-name = *( unreserved / pct-encoded / sub-delims )
      path = path-abempty ; begins with "/" or is empty
              / path-absolute ; begins with "/" but not "//"
            / path-noscheme ; begins with a non-colon segment
          / path-rootless ; begins with a segment
          / path-empty ; zero characters
      path-abempty = *( "/" segment )
      path-absolute = "/" [ segment-nz *( "/" segment ) ]
      path-noscheme = segment-nz-nc *( "/" segment )
      path-rootless = segment-nz *( "/" segment )
      path-empty = 0
      segment = *pchar
      segment-nz = 1*pchar
      segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" ) ; non-zero-length segment without any colon ":"
      pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
      query = *( pchar / "/" / "?" )
      fragment = *( pchar / "/" / "?" )
      pct-encoded = "%" HEXDIG HEXDIG
      unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
      reserved = gen-delims / sub-delims
      gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
      sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

      Still no SERVER.WHATEVER syntax and no requirement for a slash at the beginning of the path.