Slashdot Mirror

There are already some ways to get some of the benefits of https: without all of the costs, and I'm sure ingenious people will figure out other work-around as well. In the meantime, from where I sit the benefits of https: generally outweigh the costs.

Let's take caching as a trivial example that doesn't require much ingenuity to figure out:

Let's say I run an https: web site. Let's say I want to run a content-delivery-network for my images, ads, and most other content but I want to maintain control of the main index.html file and of a few other "embedded" items. The end user loads the https://.../index.html. Based on the customer's IP address the index.html file will include https: links to nearby CND-offered images, ads, etc. Since the CDN's URL will have a valid certificate, there won't be certificate issues for these items. As long as the end user's web browser tolerates an https: web site embedding content from a different https: web site this will work.

Click a link. It goes through G's servers first then to the target. This is not the cache link but the "direct" site link. Can you say SLOW !! And some won't work at all !! E-V-I-L !!

I hand edit the links: remove all before the target's http://.../ and everything from &sa after.

Legal requirements on technology companies are often poorly written, and not actually sensible, as the lawyers involved may not properly understand the internet.

It's quite plausible that they used standard boilerplate 'Do not delete, modify, or ...the file at http://.../ which could not reasonably be read as allowing them to be pulled offline, as that would be a modification.

I think you shouldn't put a price on the book, but do mention the possibility of donation in the book (in the preface and possibly elsewhere). Write something like "if you enjoy this book or find it useful, please consider donating a small sum at my web page http://.../ to help me create more free books."

1. Internet addressing method changes completely in 20+ years, and memorial site is no longer accessible because nobody uses http://.../ for anything, and there aren't any servers running that protocol anymore.
2. Civilization collapses and internet infrastructure is gone, leaving your QR code pointless even if people are able to figure out how to decipher it when civilization eventually recovers.
3. Provider experiences catastrophic systems failure, all sites hosted (including your memorial) are lost.
4. Trust runs out of money due to bad investments or rapidly increasing costs, and provider shuts down site due to lack of payment.
5. QR codes fall out of popularity, as something else becomes popular instead (which then also falls out of popularity, and is replaced by yet another thing), scanning software becomes unavailable, and people wonder why grave markers from 100 years ago all have that weird staticy-looking square on them. Historians hypothesize that it was some kind of tribal identification symbol. Also, they regret that there's no actual useful information about the people buried there.

Like the GP said, you can include the bio in the QR code. Again though, this seems pointless when you can use the same space to just carve the bio in human readable characters if you want it included at all. If you're totally opposed to normal people being able to read it just by looking at the stone with their eyes, have it done in Klingon or something.

Girl, you still need more training. The actions of some states a long time ago in supporting sterilization programs do not make the USA a bad place to live right now. Nobody does that anymore. Nobody (in charge) even _wants_ to do that anymore. Things are better now. Obviously you're mad about injustices of history, which is fine and good, but the comparison between the USA and China was about the present day, not the past, so your remarks on that score were irrelevant.

In which country could you post the following statements on your blog without worrying about the government arresting you?

- "The government of my country is totally corrupt, and they ought to be deposed and replaced democratically."
- "Guess what, guys, I have joined the 'xyz' religion! Come meet at my house this afternoon to observe religious services with me!"
- "Here are links to books on the subject of civil liberties: http://.../ ."

Obviously, in the USA you can post that stuff all day and it's no problem. Any of the three items above could get you locked up in China. So get more training, girl. It will serve you well.

Or less cynically, an attempt to make Chromium support smaller/more compact displays such as on netbooks where users are less likely to accrue lots of tabs anyway. Combining the navigation buttons and tab list seems like a good way to save a bit of vertical screen space.

I assume there will be a way to bring up a URL entry box in that mode (F6/Ctrl-L).

Recent versions of Chrome hide the scheme from the URI (tech.slashdot.org/story/... rather than http://.../ which makes it easier to see the domain name of the current site at a glance, and they use a different way of showing sites with a valid SSL certificate (it shows the owner of the certificate in a green box, or some serious warning for failed certificates. Looking at the images in TFA, it suggests it may still show the domain somehow for the current tab.

The Android browser approach of making the URI box at the top of the page once it has finished loading is an interesting move; maybe a similar thing would work for showing the domain name.

I've successfully logged into Facebook using https://.../ and requested pages like that, but invariably, I am redirected back to the plaintext URL. I guess I could be truly paranoid and say it's the US gov't doing this, but I don't think so.

Yeah -- I just tried https://slashdot.org/ and got redirected to http://.../

Not cool.

After typing in www.google.com to play some Pac-Man yesterday I was saddened to see the regular logo instead of the game but then I noticed I was at https://www.google.com/. At first I thought all requests to http://.../ were being redirected to https://.../ but after a couple reloads I was back at http://.../ and Pac-Man, and even when I typed in https://.../ it redirected me back to http://./

My question now is, how long until the built-in browser search box in Safari uses this? (I'm sure the one in Firefox can handle this already, or will soon.) Another question: why not use https all the time? I know it's a bit more CPU to encrypt things, which is unnoticeable on modern clients, but how much of a strain is it on servers? Also, are there any popular clients out that don't support it? Is there any reason not to go all https all the time?

After typing in www.google.com to play some Pac-Man yesterday I was saddened to see the regular logo instead of the game but then I noticed I was at https://www.google.com/. At first I thought all requests to http://.../ were being redirected to https://.../ but after a couple reloads I was back at http://.../ and Pac-Man, and even when I typed in https://.../ it redirected me back to http://./

My question now is, how long until the built-in browser search box in Safari uses this? (I'm sure the one in Firefox can handle this already, or will soon.) Another question: why not use https all the time? I know it's a bit more CPU to encrypt things, which is unnoticeable on modern clients, but how much of a strain is it on servers? Also, are there any popular clients out that don't support it? Is there any reason not to go all https all the time?

After typing in www.google.com to play some Pac-Man yesterday I was saddened to see the regular logo instead of the game but then I noticed I was at https://www.google.com/. At first I thought all requests to http://.../ were being redirected to https://.../ but after a couple reloads I was back at http://.../ and Pac-Man, and even when I typed in https://.../ it redirected me back to http://./

My question now is, how long until the built-in browser search box in Safari uses this? (I'm sure the one in Firefox can handle this already, or will soon.) Another question: why not use https all the time? I know it's a bit more CPU to encrypt things, which is unnoticeable on modern clients, but how much of a strain is it on servers? Also, are there any popular clients out that don't support it? Is there any reason not to go all https all the time?

After typing in www.google.com to play some Pac-Man yesterday I was saddened to see the regular logo instead of the game but then I noticed I was at https://www.google.com/. At first I thought all requests to http://.../ were being redirected to https://.../ but after a couple reloads I was back at http://.../ and Pac-Man, and even when I typed in https://.../ it redirected me back to http://./

My question now is, how long until the built-in browser search box in Safari uses this? (I'm sure the one in Firefox can handle this already, or will soon.) Another question: why not use https all the time? I know it's a bit more CPU to encrypt things, which is unnoticeable on modern clients, but how much of a strain is it on servers? Also, are there any popular clients out that don't support it? Is there any reason not to go all https all the time?

HTML is plain old text.

No, its not. It has tags which are meant to convey data to a user agent and affect the rendering of the "plain old text" content, but not to be rendered as "plain old text".

what exactly is the need for this canonical business again?

The need for a mechanism of communicating the preferred and reliable short-form URL for an HTML document within the document is similar to the need to communicate a permalink within the document -- to provide something that can be stored or transmitted that the resource owner asserts will link back to the document reliably over an extended time. The particular need for the short-form URL is to support something that can easily be communicated in media that rely on a human reading and reproducing the URL -- SMS is one such medium, but print is also a medium which benefits from having reliable short-form URLs (and actually is more likely to be affected by whether those are durable over time than SMS.)

And why canonical, why not http://...?a=a or ...?a=b

I have no idea what you are trying to say with those http URL examples. As for why the particular use of the rev link attribute or the canonical value, since I said in the post you responded to that those were bad choices to fill this need, you probably shouldn't ask me why they are good choices. OTOH, you seem to be suggesting that you'd use something in the URL rather than a link attribute, which doesn't seem to make any sense. Perhaps I'm misunderstanding you and you'd like to clarify what it is you are suggesting.

If ones twitter post requires several individual SMSezes all muxed up transparently by the phone, then in this day and age, it really needs to 'just work already'

The issue, which you seem to be missing entirely, is providing information in webpages identifying URL that can be used to access the page itself which is suitable for media where (1) hypertext is not supported, and (2) characters are at a premium for cost or other reasons, and (3) a human will need to transfer the link from that medium to a browser rather than relying on a computer to do it.

I'd prefer using tags with an appropriate rel attribute to using tags with a rev or rel attribtue, since tags are just as easy to harvest programmatically, and can be accessed by users with browsers with no special support, and because visibility is good.

HTML is plain old text. SMS is also plain old text. In the GSM spec there is support for multi-part messages, so what exactly is the need for this canonical business again? And why canonical, why not http://...?a=a or ...?a=b The meaning is entirely arbitrary, it matters only to the person writing the link or the geek coding the back end system to interpret it. If ones twitter post requires several individual SMSezes all muxed up transparently by the phone, then in this day and age, it really needs to 'just work already' Maybe it does, maybe I'm missing something here? The article didn't entirely make sense to me anyway.

Fraud is so prevelent the banks have written it off as a cost of doing business. I had my account compromised a couple of months ago. I called the bank on the same day that I noticed the fraud and by the end of the day they had credited my account for the fraud, opened an investigation, and setup a new account for me. I didn't even need to redo any of my direct deposits, or automatic billing because it all transfered over to the new account. Wells Fargo calls it a "lost stolen transfer". I'm sure that other banks have similar catchy phrases for their own process.

In my case, I made the mistake of buying WoW gold from China. It always comes down to user education. If a person knows how to use a computer, they can make educated decisions and keep themselves safe. I live in Long Beach, CA and my city has a couple of classes a month about how to avoid online fraud. They are directed toward seniors and anyone else who is interested. I haven't been to one, but they probably just cover the basics. "Your financial institution will never contact you asking for your personal information." "Unless you initiate the transaction, it's probably suspect." "This is how you type https://.../ into the web browser."

The iGoogle GMail changes are totally confusing and buggy. When I checked it yesterday, links (or rather http://.../ lines in an e-amil) in the iGoogle "partial GMail" version weren't linkified while in the full GMail they are. I've no idea what they were shooting for with the new IGoogle GMail - you've now got the embedded version as before, as well as the full GMail itself, but now also this bizarre useless maximized version of the embedded version.

lynx https://www.paypal.com/
SSL error:no issuer was found-Continue? (y) y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: cookie_check=yes Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: navcmd=_home-general Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: navlns=0.0 Allow? (Y/N/Always/neVer)y
# FINALLY there's a homepage. "Member Log In" is on the second page.
SSL error:no issuer was found-Continue? (y) y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
Refresh: 1 seconds
https://.../
SSL error:no issuer was found-Continue? (y) y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y
www.paypal.com cookie: (censored) Allow? (Y/N/Always/neVer)y ...

Ok, if I'd hit "a" to those cookies, it would've been a lot better. And there are a fscking LOT of cookies.

Now, I haven't actually tried to do anything with it so far, but I suspect that it would, in fact, work just fine. It's curious that it doesn't like the SSL -- I suspect that's a problem with my version of Lynx, as Firefox and Konqueror don't give me any SSL warnings. But other than that, Paypal isn't doing anything to block Lynx, and it looks reasonably navigateable.

I've just got a lump of space on a whitebox PC (mirrored disks with ZFS on Solaris 10, but others will prefer Linux) served up with the Apache WebDAV module (which ships with Solaris). Were I really paranoid I'd create a zone to run the web server in, but as things stand it's not running as root and I'm reasonably comfortable with the security as it stands. The authentication is standard Apache, but I've forced all access to the directory to be via https to avoid sniffing (the data centre is actually a University CS department machine room). Access from Mac is standard OSX stuff (just sue the Finder to map https://.../ from Windows is Web Folders (again, https works) and from LInux is davfs2. Solaris is a little trickier...

Outlook hides important data, like the full email address and the list of people in a group. If you accept an appointment quickly you will never be able to find it again, because the email is deleted, and filed somewhere in the calender.
Can't recognise urls... like if you paste http://.../ as text into a email most other programs convert it to a hyperlink. Even when it does recognise it can't handle spaces in urls. Pasting images into an email embeds them as uncompressed bitmaps. Extreemly hard to search for keywords in mails. Should just be able to search all emails with one click, regardless of what folder they are in. ... and if I used it more I could make a much bigger list

After reading all the comments, this one seems the only that makes sense.

Whitelists / blacklists / Trusted Computing are based upon some "authority" who decides who is evil, and who is good. That is, at least, undesirable, not to say it is uneffective.

The fact is that, as someone else commented, THE USER puts the systems in risk, by your own ignorance about basic security principles. But... the user should not be supposed to be a geek, or a security-conscious person! - you cannot expect that the user has to observe the tiny padlock at the corner of a browser, or to understand the difference between http:/// and https://.../ In a networked system, the user itself has to be considered untrusted.

so, the conclusion seems to be obvious:

Everything which runs on user space should be sandboxed, and run with minimal privileges, so it can do any harm.

The HARM is the focus. I really dont care if my system is infected by a virus, but it cant do anything evil.

And furthermore, if you use google via a customised google page (http://www.google.com/ig) then even if you redirect that to https://.../ then the link to GMail is still regular http.

I don't understand why e-mail readers allow the \\ HTML tags. If they were ignored and only http://.../ text was automatically converted to links, then it would be much more obvious that a link was to a site other than that given by the text of the link.

Because this traverses whole HTML file and associates and converts everything external in it to data:

I tried making this in javascript, basing on the old good Hixie's data: URI kitchen rewritten in js, but sorry, stumbled against a hard block - you can't automatically import -contents- of an image or external script or stylesheet into a JS object which you could transform later. Of course you can do var pic=new Image() but then you can do really little with the contents - there is no way to access the raw binary of the image to process it. So in fact you need a HTML, CSS (and possibly JS too) parser that will download all external files, parse them to find any further references (background-image: url(http://.../ in external style sheet?) and recursively replace all with respective data: URIs.
In the short half-hour before I gave up on my little converter, I pondered this thoroughly and the idea is way harder to do than it looks. Generally you need a good spider backend for seeking whatever needs to be inlined, then imports it in parseable way, starting from deepest nesting - and that's the hard part - the actual conversion is trivial.

Short list of things to consider:
-script src=..
--inside script: object.src=...
-link rel= (stylesheet)
--inside stylesheet: background-image:url(...);
-object, embed, applet
--their respective prerequisites?? flash loaded from inside flash?
-any element with background="..."
-any element with longdesc="..."
-img
-input type=image
-frame
-iframe
-any HTML, script and style already embedded as data: URI needs to be decoded first to see if it doesn't contain unencapsulated URLs as well.

Quite a few of the above need to be re-parsed for deeper linkage too. Likely there are some more I missed too.

Ok,

First, this site does present a falsifiable theory, because it does make predictions. It's too bad they get most of the predictions made by the other side wrong.

This is different from most "ID", as in typical ID pains are taken to not present any information about the creator or the creator's motives, etc. The site even explains this. I personally think it is funny that here we have an ID site complaining about the poor science of most IDers. Yeah, guys, we noticed that too.

They have made a mistake in saying that evolutionary, or "Anti-Supernatural" as they label it, theory predicts that "Complex new designs would be rare and develop slowly whereas simple transitions would be common". This was once true, but they seem to have missed out on the whole punctuated equilibrium thing that was a big deal in evolutionary theory about, oh, 20-30 years ago. Perhaps they would like to point out problems with the phlogiston theory also. Poking holes in old, discarded theories must be very difficult. Also they state that their theory places "No restraints" upon the recovery or transition times. No restrictions is not a prediction. They would do well to state what their predicted time periods of change and recovery would be. If their model does not do this, this is not an advantage. A theory which does NOT tell us something is not preferable to something which does.

In addition, their model is "bible-based". It is intellectually dishonest to use the bible as the basis for a scientific theory without also mentioning all the times throughout history when scientific theories based upon scripture have been proven false (Copernicus would like a word with you). This does not by any means prove their theory wrong, but it can be used to prove that basing scientific theories upon the bible is often a way to end up with a wrong result (this would be a criticism of methodology).

So, lets look at the predictions:
1) There is only one universe. Not much disagreement with the vast majority of scientists on that prediction. Maybe they have been talking to David Deutsch to get their multiverse prediction from the "Anti-supernatural" camp. So this cannot be used as evidence to distinguish between the two theories.

2) Fine Tuning. This is a cosmology argument. What is it doing in an arguement about biological evolution? Who got their chocolate in my peanut butter?

3) Uniqueness of Earth. This is a valid prediction. When enough evidence is gathered, then we will see what the answer is. Right now the inability to detect earth-sized planets leaves this as an open question.

4) Existence of Life in our universe. This makes a valid prediction. Also an open question as in 3.

5) Prebiotic chemistry. This makes a valid prediction: that of all the chemicals required for life, that one or more cannot be generated by naturalistic processes. So far, naturalistic processes for some of the chemicals have been found. Because there are a limited number of chemicals required for life, it is difficult but possible that naturalistic processes could be found for all of them. However, unless it is proven that it is impossible for one of those chemicals to be formed naturalistically, this prediction is still an open question. This really is about the Origin of Life . Stop getting your chocolate in my peanut butter!

6) This is the Origin of life question. They say the naturalistic theory predicts that "Life emerged late, during ideal environmental conditions. Life began as simple systems (pre-bacteria)" and that their theory predicts that "Life emerged early under adverse conditions. Life has always been complex." Did they get part of this backwards? Are they really predicting that life began earlier than 4 billion years ago, and that conditions were worse than the oxygen-poor conditions on earth at that time? Also, it should be pointed out that their prediction that life has alwa

Priceless :-)