Slashdot Mirror

Does anybody know (or at least want to take a guess) how this shit's supposed to work? How do you store this unique ID without using cookies, or something that works just like cookies?

First, Google owns the ad networks - the vast majority of them, anyhow.

So what Google does is when you download a page using Google's ad networks, Google takes their cookie that identifies you (either anonymously, or named, if you use Google+/Google ID), and translates that to a number, probably by hashing it. Google then passes the ad URL appending the hashed identifier.

You know, like how instead of retrieving http://example.com/ad_image.gif, they'll do http://example.com/ad_image.gif?adid=blahblah.

Of course, it'll only work on Google owned ad networks, but since they own the vast majority of it, well, that's practically all you're likely to encounter.

Does anybody know (or at least want to take a guess) how this shit's supposed to work? How do you store this unique ID without using cookies, or something that works just like cookies?

First, Google owns the ad networks - the vast majority of them, anyhow.

So what Google does is when you download a page using Google's ad networks, Google takes their cookie that identifies you (either anonymously, or named, if you use Google+/Google ID), and translates that to a number, probably by hashing it. Google then passes the ad URL appending the hashed identifier.

You know, like how instead of retrieving http://example.com/ad_image.gif, they'll do http://example.com/ad_image.gif?adid=blahblah.

Of course, it'll only work on Google owned ad networks, but since they own the vast majority of it, well, that's practically all you're likely to encounter.

Modifying the behavior for "cross-domain" requests doesn't fix a thing. What if I open up a malicious link from my mail client?

https://bank.example.com/transfer?to=mallory&amount=100

Your idea of a "fix" doesn't fix anything, it ignores the Web security model and naively assumes that there's some hard distinction between "The user wanted to perform this action" and "some non-user performed this action acting as the user" when, to the user-agent and end server, there's really no distinction.

On the Web, only user-agents make requests. If they're doing this because a human requested it or because a program or robot made the request is immaterial. Requests should must be secure under all these conditions.

There are reserved domains for just that purpose. This isn't a whoosh - this is one of those moments where you initiate direct eye contact and say, "REALLY?!"

It was an otherwise informative comment which will get down-voted, so I'll re-phrase with a word of caution.

Does the other guy have a website, and work in a different profession? If so, create your own simple page with your CV, and put a note near the top "Looking for K. Ackle of Loudmouthville, TX? Click [here]".

But be careful not to appear to be linking to someone who is simply more popular than you - so choose a brief way of implying he's just a different person, not that you constantly get messages from people trying to contact him and are annoyed by it. It's a very thin line, and your circumstances will dictate what is best to use.

Same here. The last version I used was 95 and I sorta liked it. I started to use Linux, because I wanted to learn more by myself.

The main thing now is that I have 24 workspaces (6 on each of the 4 screens) and I do not use Xinerama (I want to switch them individually)

Not sure if this would be possible with http://virtuawin.sourceforge.net/ or http://www.dexpot.de/index.php?id=home or others.
As it is not even easy to do under Linux (GNOME and KDE use Xinerama by default) I would not dare to try it.

Another thing is the ease of installing programs. I use YaST or just go to http://software.opensuse.org/ and I have almost anything I would need. In very seldom cases I do `sudo rpm -Uvh http://example.com/program.rpm` and be done with it. I have nothing that I compile myself. Updates are done from one place that is already configured from the start.

When I do a new installation, all the software that I need is already there right at my fingertips in one location. If I want to be a noob, it works. If I want to be a ubergeek, I have the tools to do anything I desire.

And last, but certainly not least, I am in control. I decide what I want. If I do not like it, I change. I do not like KDE or GNOME, so I use XFCE. If I want, I can use something else. And all that available without really searching the web for it.

So for me 1997 has been the year of the Linux desktop. The sole thing that keeps it from becoming it for everybody is pre-instalation. Have it pre-installed and people will use it. They use Android. They use MacOS. Why? Because it is pre-installed. Many people do not even know what Windows is. They don't care. They have their computer and they click on Internet and they can send a mail to friends and family, play a game, watch Youtube, use Facebook and search for free porn.

"The idea that as soon as you're talking about the internet, anything you can do should be legal, is a bit strange."

Did I say that "anything I can do [on Internet] should be legal"? No, did I?

"If faced with a login screen, behind which javascript implements completely inadequate security..."

For a starter, since you talk about trespassing, that javascript code is in *my* premises, downloaded to *my* PC and sent to *my* browser, and then, only *after* I politely asked to the server to send me what it sees fit.

Now again, if I politely salute a server with http://www.example.com/data?tell=me&your=secrets why should I be responsible for what the server, not me, decided to send back to me? Do you really consider burglary if I politely ask you to give me a grand and then you give me a grand?

And finally, what do you think that funny "www" in the begining means? It means "World Wide [Web]". So you put something reachable by the world at wide, explicitly meant to be reached by the world at wide and still you think no level of due diligence should be requested before throwing criminal charges to other people?

"Stealing money that's sitting poking out of someone's bag while they're not looking is still stealing"

I see you don't understand... there's no way I can unadvertidly poke something out of a web server: I need to *request* the server, and the server then answer my request the way it sees fit.

"Now this doesn't even make sense."

Yes, it does. When you in real world put a door in a mall, with a big "WELCOME" sign at the top, then you can't argue you didn't allow in some explicit person unless you explicitly tell him he's not welcome.

Well, that's exactly what a website is in Internet world: you just can't say that I'm not allowed to enter http://www.example.com/data?tell=me&your=secrets post-facto, because it's a very valid entry point to an explicitly public place.

Law-makers should understand this. Well, law-makers do in fact know this. And they don't give a damn.

And why do you think the request would not be coming from a previously authenticated browser? The malware can work through your regular IE install, to send a page request for https://actualbankwebsite.com/login in a window you don't see. Then show the user an identical looking login page (copied from the real one) in a security-compromised browser window. Now the malware can grab the login credentials, pass them along to the real bank webpage, and initiate a funds transfer to some other (compromised) bank account. Finally, return the user's view to the already-logged-in actual bank page, so they won't even know what hit them. Intercept and delete any confirmation emails about the impending transfer coming from the bank.

It doesn't matter whether there is other use of the domain or not. Microsoft will be able to show this as bad faith use of the domain. Even if there are other uses of the domain that weren't in bad faith -- if bad faith use can be proven, then MS wins. Creating http://example.com/ as a page with just ADs has been taken by UDRP panels as evidence of bad-faith use, which is enough to grant the UDRP dispute claim to Microsoft.

Exactly. Us professionals run sqlmap --level 5 --risk 5 -u http://example.com/foo.php instead.

no. it's a bug. the HTML5 spec clearly states that this exact behaviour should be looked out for and blocked

Its not a bug. While the Web Storage API Candidate Recommendation (related to, but not part, of, the HTML5 spec) both says that user agents should set a per-origin storage limit and should identify and prevent use of "origins of affiliated sites" to circumvent that limit, it doesn't specify either what constitutes an "affiliated site", and neither of those things that it says "should" be done are requirements of the specification. "Should" has a quite specific meaning in the specification (defined by reference in the spec to RFC2119), and its not the same as "must", instead:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So, its both a recommendation rather than a requirement, and not specified clearly enough to be implemented. There are some cases where origins of the same second-level domain are meaningfully affiliated, and some times where they are not (for a clear case of the latter, consider subdomains of ".co.uk".) Its pretty clear that origins which differ only in protocol are almost always going to be affiliated by any reasonable definition (e.g., http://www.example.com/ and https://www.example.com/ which are different origins), but no automatic identification of origin affiliation by subdomain can be done simply without understanding of per-domain policies from the TLD down to the first level at which all subdomains are affiliated. (And this is a problem which will get worse with the planned explosion of TLDs.) W

no. it's a bug. the HTML5 spec clearly states that this exact behaviour should be looked out for and blocked

Its not a bug. While the Web Storage API Candidate Recommendation (related to, but not part, of, the HTML5 spec) both says that user agents should set a per-origin storage limit and should identify and prevent use of "origins of affiliated sites" to circumvent that limit, it doesn't specify either what constitutes an "affiliated site", and neither of those things that it says "should" be done are requirements of the specification. "Should" has a quite specific meaning in the specification (defined by reference in the spec to RFC2119), and its not the same as "must", instead:

SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

So, its both a recommendation rather than a requirement, and not specified clearly enough to be implemented. There are some cases where origins of the same second-level domain are meaningfully affiliated, and some times where they are not (for a clear case of the latter, consider subdomains of ".co.uk".) Its pretty clear that origins which differ only in protocol are almost always going to be affiliated by any reasonable definition (e.g., http://www.example.com/ and https://www.example.com/ which are different origins), but no automatic identification of origin affiliation by subdomain can be done simply without understanding of per-domain policies from the TLD down to the first level at which all subdomains are affiliated. (And this is a problem which will get worse with the planned explosion of TLDs.) W

wbr1 makes a great point. Slashdot's blog is amazing. My friend's mom's parakeet makes $375 a day from home. It's totally legal and she didn't believe it could be done. http://isuck.example.com/gv56tgy

Am I the only one not impressed by this?
Lets say url crafted is: http://www.example.com/some-spam-page.php?email=joe@example.com&id=f5b8fb60c6116331da07c65b96a8a1d1
<?php
$md5_check = md5($_GET['email'].'SomeSuperAwesomelyRandomSeedHere');
if($md5_check!=$_GET['id']){
header("Location: /404.php");
die();
}
// display phishing page
?>
Well that took me 30 seconds to come up with.

Could you point /etc/apt/sources.list to an authenticated http://example.com/apt-repo and tailor the content served depending on the user???

you can bet your arse that if Google decided to run on the front page "Larry Page is a homosexual" on the front page the courts would not like it either.

First, I don't think that the courts would really care if Google said their founder was gay or not. Page might, especially if he wasn't and/or was in the closet about it. And it would be a case between Page and his company.

Regardless though, Google isn't saying "Larry Page is a homosexual". Google is more like saying "The website http://www.example.com/index.html says Larry Page is a homosexual". Libel can't be libel if it's a fact. And if a webpage does say that, even if the underlying statement is untrue, the website did actually state that. Or at least that was what I use to think prior to this case.

Use HTML:

<a href=url_goes_here>text goes here</a>

text goes here

Or:

<URL:http://example.com/>

http://example.com/

I do something a bit different. I tend to put any admin tools up in an /admin directory (ex, https://example.com/admin/phpmyadmin), then use HTTP basic authentication to require users to authenticate with a username/password in our LDAP directory (but you could use local shell accounts as well). That way someone would need to first compromise a user account before they could even *start* trying to compromise one of the admin tools. I tend to think of it as a similar idea to not allowing remote root logins in ssh. Login first and sudo/su. I'm actually surprised that this isn't used more often. Am I missing an obvious security implication? Or is it just a case of people being lazy?

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

This one I didn't understand. If you wanted to do this, why not have something like

ftp://example.com 2001:f00:ba7:2::5:21
http://example.com/ 2001:f00:ba7:2::5:8080

In the above case, you can use ftp port# 21 to indicate that it's FTP, and 8080 to indicate http. Since the port# are from 0 to 65535, you could even convert that into HEX, if there were a wide range of protocols you were using.

So I didn't exactly get your issue w/ this one.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

This one I didn't understand. If you wanted to do this, why not have something like

ftp://example.com 2001:f00:ba7:2::5:21
http://example.com/ 2001:f00:ba7:2::5:8080

In the above case, you can use ftp port# 21 to indicate that it's FTP, and 8080 to indicate http. Since the port# are from 0 to 65535, you could even convert that into HEX, if there were a wide range of protocols you were using.

So I didn't exactly get your issue w/ this one.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

This one I didn't understand. If you wanted to do this, why not have something like

ftp://example.com 2001:f00:ba7:2::5:21
http://example.com/ 2001:f00:ba7:2::5:8080

In the above case, you can use ftp port# 21 to indicate that it's FTP, and 8080 to indicate http. Since the port# are from 0 to 65535, you could even convert that into HEX, if there were a wide range of protocols you were using.

So I didn't exactly get your issue w/ this one.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

This one I didn't understand. If you wanted to do this, why not have something like

ftp://example.com 2001:f00:ba7:2::5:21
http://example.com/ 2001:f00:ba7:2::5:8080

In the above case, you can use ftp port# 21 to indicate that it's FTP, and 8080 to indicate http. Since the port# are from 0 to 65535, you could even convert that into HEX, if there were a wide range of protocols you were using.

So I didn't exactly get your issue w/ this one.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

This one I didn't understand. If you wanted to do this, why not have something like

ftp://example.com 2001:f00:ba7:2::5:21
http://example.com/ 2001:f00:ba7:2::5:8080

In the above case, you can use ftp port# 21 to indicate that it's FTP, and 8080 to indicate http. Since the port# are from 0 to 65535, you could even convert that into HEX, if there were a wide range of protocols you were using.

So I didn't exactly get your issue w/ this one.

Too bad. Now every time I want to switch to a backup ISP (when the main connection goes down) I'll have to reconfigure all computers in the internal network (maybe some script will be able to do it automatically).

This is what router advertisements are for. You switch ISP, your router starts advertising the new prefix, everything carries on working. (If you're really smart you'll use IPv6 mobility extensions, although that would require some support from your ISP since your connection has died).

If I ever wanted to load balance between two ISPs and use standard software that would be impossible.

Now this one is something that I haven't seen a good solution to (without having a PI prefix and support from the ISPs). But then again, I haven't looked very hard.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too.

That's what SRV records are for (although admittedly I doubt any FTP clients and web browsers support them, but they work well for a lot of other protocols).

If I wanted to make a server believe that two clients are actually the same one - that would be impossible too.

Uh.. why would you want to?

No more transparent proxies - remember the special URL to log in to the ISP (now you just get redirected there)

Transparent proxies work just fine.

NAT has more uses other than the "share one external IP to multiple computers".

Very few. Most of which can be better implemented without NAT (e.g. using IPv6's mobility extensions, etc.) On the other hand, the fact that practically everything goes through a NAT causes all sorts of brokenness that I would be more than happy to not have to deal with. I'm willing to live without the relatively minor benefits of NAT if I get to avoid having to put up with the brokenness it induces.

Too bad. Now every time I want to switch to a backup ISP (when the main connection goes down) I'll have to reconfigure all computers in the internal network (maybe some script will be able to do it automatically). After all, the other ISP will give different IPs and instead of the router just using whatever external IP it has and the PCs not caring, now the connection will be disrupted for some time until all PCs realize that the main connection is dead.

If I ever wanted to load balance between two ISPs and use standard software that would be impossible.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

If I wanted to make a server believe that two clients are actually the same one - that would be impossible too. Well, I could use a proxy server, but that requires that the client software supports using proxies.

No more transparent proxies - remember the special URL to log in to the ISP (now you just get redirected there) and no more upside-down-ternet.

NAT has more uses other than the "share one external IP to multiple computers".

Too bad. Now every time I want to switch to a backup ISP (when the main connection goes down) I'll have to reconfigure all computers in the internal network (maybe some script will be able to do it automatically). After all, the other ISP will give different IPs and instead of the router just using whatever external IP it has and the PCs not caring, now the connection will be disrupted for some time until all PCs realize that the main connection is dead.

If I ever wanted to load balance between two ISPs and use standard software that would be impossible.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

If I wanted to make a server believe that two clients are actually the same one - that would be impossible too. Well, I could use a proxy server, but that requires that the client software supports using proxies.

No more transparent proxies - remember the special URL to log in to the ISP (now you just get redirected there) and no more upside-down-ternet.

NAT has more uses other than the "share one external IP to multiple computers".

Too bad. Now every time I want to switch to a backup ISP (when the main connection goes down) I'll have to reconfigure all computers in the internal network (maybe some script will be able to do it automatically). After all, the other ISP will give different IPs and instead of the router just using whatever external IP it has and the PCs not caring, now the connection will be disrupted for some time until all PCs realize that the main connection is dead.

If I ever wanted to load balance between two ISPs and use standard software that would be impossible.

If I ever wanted to make ftp://example.com and http://example/ com be different actual servers, that would be impossible too. Maybe I could use very similar names - http://i.example.com/ and ftp://l.example.com but that is not the same.

If I wanted to make a server believe that two clients are actually the same one - that would be impossible too. Well, I could use a proxy server, but that requires that the client software supports using proxies.

No more transparent proxies - remember the special URL to log in to the ISP (now you just get redirected there) and no more upside-down-ternet.

NAT has more uses other than the "share one external IP to multiple computers".

No, the problem is users uploading content containing javascript. Then referencing this javascript from an external site. When a user who happens to also be logged into the popular site hosting my content views my page my javascript executes in the context of the other sites domain with access to the users credentials.

I'm surprised no one else has pointed this out before. The domain security model is broken. Period. It's time to move beyond that and to an explicit capability system that is granular enough to reference individual URIs, and even *that* is probably insufficient. It is entirely reasonable that a trusted script at http://trusted.example.com/trusted_path/trusted_handler.js?script=1 should be able to *not trust* http://trusted.example.com/trusted_path/trusted_handler.js?script=2, and further that even http://trusted.example.com/trusted_path/trusted_handler.js?script=1 should not be trusted if any cookie available to trusted.example.com is added, modified, or deleted between the time the URIs are fetched.

No, the problem is users uploading content containing javascript. Then referencing this javascript from an external site. When a user who happens to also be logged into the popular site hosting my content views my page my javascript executes in the context of the other sites domain with access to the users credentials.

I'm surprised no one else has pointed this out before. The domain security model is broken. Period. It's time to move beyond that and to an explicit capability system that is granular enough to reference individual URIs, and even *that* is probably insufficient. It is entirely reasonable that a trusted script at http://trusted.example.com/trusted_path/trusted_handler.js?script=1 should be able to *not trust* http://trusted.example.com/trusted_path/trusted_handler.js?script=2, and further that even http://trusted.example.com/trusted_path/trusted_handler.js?script=1 should not be trusted if any cookie available to trusted.example.com is added, modified, or deleted between the time the URIs are fetched.

No, the problem is users uploading content containing javascript. Then referencing this javascript from an external site. When a user who happens to also be logged into the popular site hosting my content views my page my javascript executes in the context of the other sites domain with access to the users credentials.

I'm surprised no one else has pointed this out before. The domain security model is broken. Period. It's time to move beyond that and to an explicit capability system that is granular enough to reference individual URIs, and even *that* is probably insufficient. It is entirely reasonable that a trusted script at http://trusted.example.com/trusted_path/trusted_handler.js?script=1 should be able to *not trust* http://trusted.example.com/trusted_path/trusted_handler.js?script=2, and further that even http://trusted.example.com/trusted_path/trusted_handler.js?script=1 should not be trusted if any cookie available to trusted.example.com is added, modified, or deleted between the time the URIs are fetched.

Who guarantees, taht downloading from http://example.com/ will really lead to your company's Servers?
DNS Poisioning is a well known and very frequent attack scheme.

Basically all your arguments AGAINST BT could be evened out by arguments AGAINST http(s)

There's only a couple of organizational schemes that make sense; Geographical, topical, and organizational. Of those, the third was the first used: Separating domains on the basis of their function; educational, commercial, non-commercial, and governmental.

On hindsight, that was not the wisest decision. It would have been better to ONLY use the geographical system. That would have meant no com, net and org.

What about things like linux.org, you might ask? Well, when I look at the whois page, I see an american address. So it would have been linux.us or if the country would have wanted: linux.org.us

Thise who want availability in more then one country can go to each country, just like they do now. Each country would be able to decide what they do with their domain, just like they do now. e.g.:Do they accept people from other countries or not?

It is hindsight, so nothing we can do about it now.

If they ever decide to start all over from 0, it would be nice that they start with the toplevel and not end with it. That would mean you would not have http://www.example.com/directory/file.html, but rather something like http://us/example/www/directory/file.txt (and even allow http:\\us\example\www\directory\file.html
Sure, it might look strange as we are not used to it, but it is more logical.

Lightning is full of bugs. Its been getting better over the years - but its so far behind Outlook and Exchange. Its a pity, because a little work with this, and it could be a very good Outlook/Exchange replacement. Cyrus-IMap is a better mail server than Exchange in every way, and the remnants of Netscape Calendar (now with Oracle) is a better calendar server in every way - its just the clients suck.

These are some wishes from semi-enterprise...
Mail:
1. No auto-configuration. Why should users have to configure mail servers - configure it through DNS srv records. (Dont get me started on the current mail configuration - theres plenty of rants here already.) If the srv records are there, it knows all of the account details, just provide a username and password and thunderbird is configured.
2. The text editor is only a minor improvement from the original netscape (and in some ways that was better.) Have a look at MCE editor for ideas on providing a better editor (and its already in javascript for easy porting)
3. Plugin deployment is difficult.

Calendar:
1. No auto-configuration. Using Caldav means adding a horrible url for each calendar you want.
2. No way of administering these calendars. - Delete, rename etc. I can add new ones, by crafting a new url.... https://caldav.example.com:8080/caldav.php/username/NewCalendar
3. No adding of modifying permissions on calendars.
4. No listing available calendars from the server. I should simply be able to list my own calendars that are on the server - and list ones available from other users, and resources.
5. Invites are still spotty.
6. Theres very little insight to when it goes wrong. no meaningful error messages - stuff just doesnt work.

Sogo is addressing some of these things, however, this should all be included functionality - core to lightning.

It really highlights some of the issues - calendars are hard, and because its a plugin - its in javascript - and thats damn hard too.
But its annoying, because its so close to being a great enterprise product.

Affero

That depends on what you call the user: In a way, it's who runs the server that a cloud application runs on. But for me, the actual user is the person who actually uses the software.

In that particular installation, maybe. Yet the license restricts everyone who runs the software elsewhere, including taking a single function from the code base.

Does the AGPL require a way to download the source code from within the software? I would have assumed that presenting a notice like "This is AGPL software, the source is at http://example.com/foo-source" would be perfectly fine.

Which is not doable, or doable with a massive inconvenience, when the interaction is something else than a webpage. What about IRC bots? What about twitter utilities? What about RSS? What about a programmable light switch?

Most hardened Free Software advocates consider Affero to be non-free. It introduces usage restrictions, which go against Freedom 0 ("the right to use the software for any purpose").

That depends on what you call the user: In a way, it's who runs the server that a cloud application runs on. But for me, the actual user is the person who actually uses the software.

It also prevents most code reuse: you can't take a part and put it inside your program if it interacts with users in a way that doesn't provide means of file transfers.

Does the AGPL require a way to download the source code from within the software? I would have assumed that presenting a notice like "This is AGPL software, the source is at http://example.com/foo-source" would be perfectly fine.

You'd think, wouldn't you! Let's find out!

If you wanted to, you could go to Google and run a search for MySpamPC. But you wouldn't find anything useful because I just made it up.

Hmm, guess not.

ooooooooooooooooooooooooooooomed!

Allowed HTML

1. • URLs
     http://example.com/ will auto-link a URL
     Important Stuff

             Please try to keep posts on topic.
             Try to reply to other people's comments instead of starting new threads.
             Read other people's messages before posting your own to avoid simply duplicating what has already been said.
             Use a clear subject that describes what your message is about.
             Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

     If you are having a problem with accounts or comment posting, please yell for help.

part of the developer program. Why is that so hard for you to understand?

A couple of replies back you said, "The advantage with iOS is", which made it seem like as if you were promoting iOS over Android. My (obtuse, perhaps) response has been that there are less hoops to jump through to develop on Android since anyone can just install the dev tools and go, no registration needed. The same goes for people testing the program. Apple on the other hand, is introducing hurdles for both parties to overcome to test the software.

If you are not part of a beta program then you just basically stole a copy of the prerelease version and you are then not beta testing anything.

There is no official beta program for the software I am testing because it's free software being written for the users' benefit. No theft is happening. The developer quite literally says "here, try this version and see if it works: http://example.com/program_beta9.apk"

Facedrive(TM)... are you tired of paying high rates for your offsite storage and backups? Fear not, for there are versions of Facedrive(TM) specifically tailored for residential, and small/medium/large businesses. Simply click on this link http://bad.example.com/, download and launch the free app that will evaluate your hard drive, and advise you if you qualify fro FREE* service.

*Restrictions may apply.

3. the user says Sure post you notifications to my notification URL http://example.com/my-notes

So just where is this user's 24/7 webservice going to be running, that can accept this "push" content? You haven't solved the problem, you've just hidden it behind a URL.

6. user checks http://example.com/my-notes for notifications

So it really is pull, just written with the letters 'p', 'u', 's' and 'h'?

If I want to check a URL for content, why not just check the URL directly?

3. the user says Sure post you notifications to my notification URL http://example.com/my-notes

So just where is this user's 24/7 webservice going to be running, that can accept this "push" content? You haven't solved the problem, you've just hidden it behind a URL.

6. user checks http://example.com/my-notes for notifications

So it really is pull, just written with the letters 'p', 'u', 's' and 'h'?

If I want to check a URL for content, why not just check the URL directly?

Yes it will, basically

1. the website ask for permision
2. the webbrowser asks the user
3. the user says Sure post you notifications to my notification URL http://example.com/my-notes
4. user checks http://example.com/my-notes for notifications
5. the website pushes notifications to the notification URL
6. user checks http://example.com/my-notes for notifications
7. user checks http://example.com/my-notes for notifications
8. user checks http://example.com/my-notes for notifications
9. user checks http://example.com/my-notes for notifications

Yes it will, basically

1. the website ask for permision
2. the webbrowser asks the user
3. the user says Sure post you notifications to my notification URL http://example.com/my-notes
4. user checks http://example.com/my-notes for notifications
5. the website pushes notifications to the notification URL
6. user checks http://example.com/my-notes for notifications
7. user checks http://example.com/my-notes for notifications
8. user checks http://example.com/my-notes for notifications
9. user checks http://example.com/my-notes for notifications

Yes it will, basically

1. the website ask for permision
2. the webbrowser asks the user
3. the user says Sure post you notifications to my notification URL http://example.com/my-notes
4. user checks http://example.com/my-notes for notifications
5. the website pushes notifications to the notification URL
6. user checks http://example.com/my-notes for notifications
7. user checks http://example.com/my-notes for notifications
8. user checks http://example.com/my-notes for notifications
9. user checks http://example.com/my-notes for notifications

Yes it will, basically

1. the website ask for permision
2. the webbrowser asks the user
3. the user says Sure post you notifications to my notification URL http://example.com/my-notes
4. user checks http://example.com/my-notes for notifications
5. the website pushes notifications to the notification URL
6. user checks http://example.com/my-notes for notifications
7. user checks http://example.com/my-notes for notifications
8. user checks http://example.com/my-notes for notifications
9. user checks http://example.com/my-notes for notifications

Yes it will, basically

1. the website ask for permision
2. the webbrowser asks the user
3. the user says Sure post you notifications to my notification URL http://example.com/my-notes
4. user checks http://example.com/my-notes for notifications
5. the website pushes notifications to the notification URL
6. user checks http://example.com/my-notes for notifications
7. user checks http://example.com/my-notes for notifications
8. user checks http://example.com/my-notes for notifications
9. user checks http://example.com/my-notes for notifications

Yes it will, basically

1. the website ask for permision
2. the webbrowser asks the user
3. the user says Sure post you notifications to my notification URL http://example.com/my-notes
4. user checks http://example.com/my-notes for notifications
5. the website pushes notifications to the notification URL
6. user checks http://example.com/my-notes for notifications
7. user checks http://example.com/my-notes for notifications
8. user checks http://example.com/my-notes for notifications
9. user checks http://example.com/my-notes for notifications

As far as I've been able to make out, while QR codes have different possible applications, the only application for which I've ever seen them used is for encoding URLs in posted advertisements. And in every case, the URL was printed adjacent to the QR code block, and usually was short and obvious, e.g., on a poster for www.example.com, there's the URL, http://www.example.com/ and a QR code, that when scanned and translated, presents the URL, http://www.example.com/. Since I'd have to take a photo of the QR code block, let it analyze the image, and accept the presented URL and open a Web browser from that link, I've ended up taking more time and going through more steps than I would have by just typing in the damned URL to begin with.

In practice, the only reason to bother with QR codes at all is for the sake of novelty, and that wears thin very quickly. If QR codes as a malware vector becomes common, I think everyone will just stop using them entirely.

As far as I've been able to make out, while QR codes have different possible applications, the only application for which I've ever seen them used is for encoding URLs in posted advertisements. And in every case, the URL was printed adjacent to the QR code block, and usually was short and obvious, e.g., on a poster for www.example.com, there's the URL, http://www.example.com/ and a QR code, that when scanned and translated, presents the URL, http://www.example.com/. Since I'd have to take a photo of the QR code block, let it analyze the image, and accept the presented URL and open a Web browser from that link, I've ended up taking more time and going through more steps than I would have by just typing in the damned URL to begin with.

In practice, the only reason to bother with QR codes at all is for the sake of novelty, and that wears thin very quickly. If QR codes as a malware vector becomes common, I think everyone will just stop using them entirely.

From Slashdot FAQ:
To "auto-link" a URL in HTML or Plain modes, enclose it in "less than"URL : http://example.com/"greater than".

It was silly not to just try the standard HTML tag. I was trying to reproduce the nice feature of showing between [] the target domain. That's why I went looking for a Slashdot's custom tag. Now I see this is a feature added to the standard tag.

Thanks.