Domain: example.net
Stories and comments across the archive that link to example.net.
Comments · 14
-
Re:What "historical predictions"?
The source for that wasn't a peer reviewed published paper but an interview with a journalist.
That's fine — I don't insist, your examples must come from a scientific magazine either.
So he wasn't saying it would never snow
He did say: "Children just aren't going to know what snow is". That means, it was not going to snow — in his opinion.
The ice free prediction by Maslowski was peer reviewed science but it was at odds with a lot of other predictions at the time.
Didn't prevent Al Gore from parroting it, did it? But fine, you can quote predictions, which were likewise disapproved by the predictor's peers at the time too.
So while Maslowski's projection may not be correct it was far from the only scientific opinion about it at the time.
In other words, contrary to frequent assertions, the science is not settled.
Ok, here's a twofer
I'm giving up... Just how can you call a single link a "twofer"? I gave you — and not for the first time — an example of the format:
Is it really so hard?
-
http://mitm.bad/cacert.crtD (create a self-signed CA certificate and sign your web site's TLS certificate with it) isn't much different from A (self-sign your web site's TLS certificate). D would appear to have the same drawback that Culture20 mentioned for A: it "gives [visitors] a false sense of security unless you can contact the site owner off channel and verify the cert manually." Visitors don't know whether a man in the middle is replacing cacert.crt, just as they don't know whether a man in the middle is replacing a self-signed TLS certificate. Perhaps posting the fingerprint of cacert.crt on widely used social networking sites might help work around this.
just publish your CA cert at http://my-toy-site.example.net/cacert.crt and link from your home page; you'll be prompted to install it in your browsers trusted key-ring.
A user agent that makes it hard to use a web site with a self-signed TLS certificate will also make it hard to install a self-signed CA certificate, especially one not downloaded from an already trusted HTTPS site, for the same reasons.
I agree with you that publishing a domain's certificate through DNSSEC is a better solution. But the fact that so many domain name registrars are also CAs for traditional TLS certificates would appear to act as an incentive against implementing DNSSEC.
-
Re:it's the browser implementation
D. Create your own CA cert
Why not create you own signing certificate, and use this to sign your key for https://my-hobby-site.example.org/. You can then install the signing cert in your browser and be happy and secure.
But what about when you want to log in from an internet cafe half-way across the world? Why, just publish your CA cert at http://my-toy-site.example.net/cacert.crt and link from your home page; you'll be prompted to install it in your browsers trusted key-ring. (Of course someone could have MITM'd your certificate install, but then that's the risk you've chosen to take by going for a self-signed cert)
Now you can have a secure connection without paying a so-called "Trusted Third Party" for the privilege, and without requiring the browser to support the easy use of self-signed certs (which we know causes damage to many people's ability to use https web-sites safely).
Personally, I hope that, in the medium term, widespread key distribution based on DNS-SEC will side step this whole issue.
-
Aggressive Spam Blocking vs. False PositivesSpammers are really aggressive. Unfortunately, this means that anything you do to prevent false positives is a potential target for them to exploit, and false positives are the bane of spam-blocking.
Some spam blockers are really aggressive also, and some of them are really difficult to interact with once they decide they don't like you. Unfortunately, AOL has a reputation for being one of them, and it has a lot of subscribers so people really care. It *is* possible to deal with AOL's policies, at least most of the time, though they apparently do a bloody inadequate job of following SMTP standards when they don't like you (e.g. silently dropping spam after accepting it as opposed to rejecting it with a 55x or whatever), but it's difficult, and some ISPs aren't very good at it.
Forwarding mail to an AOL account without spam-filtering it first is one classic problem ISPs face. Either you make sure you filter the spam (which still risks false positives, and also risks missing some potential spams that AOL's rules rejected but yours didn't), or you do something to make AOL not notice that you sent them mail they think is spam.- Maybe you just refuse to forward mail to AOL.
- Maybe you need to encrypt all the emails you forward, so AOL just sees "Encrypted message #12345 forwarded from user@example.net" and has to decrypt it to find out that it's spam.
- Maybe you don't forward the message itself, but a note about "Pick up your forwarded email at https://example.net/~user/mail/12345".
- Maybe you keep a pool of different email server IP addresses, round-robin your email forwarding to AOL among the ones it hasn't blocked yet
:-)
I run a much smaller mailing list - a few hundred people, 2-3 messages a week on the main list. Fairly often I get bouncegrams back about greylisting, some of which are quite obscure, depending on what lies the greylister is telling the sender. And sometimes it's just hard to tell what the bouncegrams are complaining about. The recent entertainment has been that somebody either on the list or somebody who knows somebody on the list seems to have a virus, so I keep getting bounces from random mailer-daemons saying that "ex-user@example.com is unknown, couldn't deliver this message (and then the virus)." They're usually distinguishable from the bouncegrams I usually get that say "550 spammers-fake-return-address@example.com: User Unknown" which are returning a copy of the majordomo help message sent to people who send mail to listname-request@mydomain.example.org.
-
Unusable Error Messages from ISPsToo many mailbox-serving-ISPs have messages like this, that say "I don't like something about your email server but I won't tell you specifically what it is. Maybe it's A, B, or C.". Sure, things A, B, and C might be Bad, but that doesn't mean that any individual one is their real objection, (especially if you're not doing any of those) so there's nothing that you as an email sender or the Email server provider or ISP that the user is using that lets you fix it. Instead, all you get to do is call the destination ISP's Tech Support Line, who tell you that something must have been wrong with your configuration, and that A, B, and C are common Bad Things that they block. And their supervisor can't tell you anything useful either, if you succeed in getting him/her.
By contrast, a message that says "You're on Blacklist X, so go away or get off the list at http://www.example.net/spammer-apologies!" is at least semi-useful, if the blacklist actually responds to questions (some do, some don't.) I usually see 451 messages from Greylisting, so just because you got blocked the first time doesn't mean your mail won't be accepted 30 minutes later.
-
Re:How am I supposed to know where/how a packet
There will be a huge area of the country that suddenly goes 'dark' as these guys put up their system in place.
That's not what BellSouth is suggesting, nor would it even be smart of them as you've correctly pointed out.
Instead, the end user would see this manifest itself as a 'delay' in the connection. Imagine one day you start to notice that your favorite "Not_A_Bellsouth_Subscriber" web site starts acting slow; pages take forever to load, etc, or you find yourself asking people who their ISP is before starting an on-line game of Quake?
But BellSouth isn't a government and has no legal right to act as a government.
It's called private property, and unlike the Telephone system, most ISP's would like to have everyone agree that they own their network lock, stock, and barrel.
That's why no one can demand that you allow them to access your WAP. And you can't demand access to theirs. This is furthe complicated by the Internet Protocol itself; if your connection suddenly develops 200ms of lag, or starts losing 50% of the packets, there's no one you can blame, let alone sue, because those functions are not guaranteed services under IP.
This is tantamount to BellSouth tossing out their common carrier status.
Common Carrier only applies to voiceband. And BellSouth wants to avoid being saddled with these regulations.
The Common Carrier concept views the (telephone) network as a pipe; when you call Aunt Mable, you're talking to her and she's talking to you. The network is just a pipe.
The FCC view of the Internet is different; when you connect to http://example.net/ you're not getting the service from example.net but rather from an access point (ISP modem bank, DSLAM, cable company router, etc) owned by your ISP. Since it's their equipment, they can pick and choose the level of service they provide.
Then the federal and state agencies involved would have to go elsewhere for their service while renogatiating their contracts (or more likely abandoning them for their new carriers.)
Not directly related to this thread, but it might interest you to know that the U. S. Federal Government currently prohibits carriers from using VoIP circuits to provide National Service/Emergency Preparedness calls. Clearly they understand something we would be wise to understand as well.
-
Re:The reason for the downturn.
Well, then, thre's the start. Post your email address here, and a URL for the "These sites are broken under IE" web site you're planning to create (if you're still planning to do that) and I'll encourage all my friends to email you every time they come across a site they think is broken.
Ok, now your just being silly. There is no system in place. Merely a discussion so far. Go ahead and shoot me emails beforehand I'll get right on them.
A job gets done when it's placed in the hands of someone who is clued, motivated and authorized. Wiki's authorize everyone, use a community feedback mechanism to sort out the clued, and don't depend on the actions of anyone who is not self-motivated. The plan you are proposing depands on cooperation between (self-motivated and possibly clued, but not authorized) spotters, (self motivated and possibly clued, but not authorized) screeners, and (weakly motivated, clearly unclued, but fully authorized) web maintainers. No single party posseses all three components, so the job will likely never get done.
Authorization at any access level doesn't inherently limit a user to any particular group. ie. an admin could submit a report.
No, but you haven't thought this through. You've specified at least two layers of volunteers (spotters and screeners) who must collect the data, but cannot do anything with the data. The only ones who can do anything with the data are not volunteers.
I acutally specified at least 3 layers, don't forget collecting of email info :) There will also be the task of changing reports to fixed should a site be made to work correctly.
So let's walk this through. I'm browsing the web. I hit a site which doesn't render properly, and in order to get done what I need to get done I need it to render properly. I click my "report it" button and say "it doesn't render properly" and off goes the report. If everything works properly, a volunteer somewhere will screen the report and send a polite letter to the web administrator for the broken page asking him to fix the problem. But guess what? Any update to the page is weeks away and I still need to get done what I need to get done. After a few cycles of "click the button, fill-in the mandatory description, fail to see results" I'm going to start hesitating to click that button, because clicking that button means I need to fill-in the mandatory description, and I'm not browsing the web in order to fill-in a mandatory description, I'm browsing the web to get done what I need to get done. Soon after, the mandatory description will start getting nonsense values like "asdfjkl;" just so I can hit "submit" rather than "cancel" (which just wastes the screener's time) and at that point the plug-in might just as well uninstall itself.
Good point (the constructive parts of the criticism are indeed welcome). I guess it makes the statistics page all that much more inportant as immediate feedback to the submitter.
So, part of this Firefox plugin will launch IE in the background, so that people can compare the pages, or are you saying that people who stumble across a page which they suspect isn't rendering properly in Firefox must then launch IE manually to view the page, make the comparison, and file the report?
Ok, you're being silly again. Automatically launching IE is overkill and a bad idea to do from firefox anyway. No sense in spawning a child process when a user can verify something is IE only simply by launching IE and checking for themselves.
If a web page on my site is broken in that it contains a broken link, I'll see the report in /var/log/httpd/error_log as soon as someone clicks on it. I do review that log and fix anything reported through this process. A simple extention of this requiring no software development at all would have people discovering http://example.net/broken_page.html doesn't render properly in their browser to -
Plenty of open alternatives
There are plenty of places you can safely point to. It's fair to assume that mailboxes at example.{com|net|org} are unmonitored. There's also me@privacy.net which bounces email with a polite notice that you don't want email from the sender. Spamcop provides the conspicuous nobody@devnull.spamcop.net, originally provided for users of their newsgroups but open to all and of course you can just use fake tlds like nobody@fake.invalid which will always be rejected before the email even leaves the spammer's servers.
If you do want to recieve email but only, say, once from a company then you'll be looking at SpamGourmet which provides simple, free, fowarding addresses that expire after X hits. -
Plenty of open alternatives
There are plenty of places you can safely point to. It's fair to assume that mailboxes at example.{com|net|org} are unmonitored. There's also me@privacy.net which bounces email with a polite notice that you don't want email from the sender. Spamcop provides the conspicuous nobody@devnull.spamcop.net, originally provided for users of their newsgroups but open to all and of course you can just use fake tlds like nobody@fake.invalid which will always be rejected before the email even leaves the spammer's servers.
If you do want to recieve email but only, say, once from a company then you'll be looking at SpamGourmet which provides simple, free, fowarding addresses that expire after X hits. -
Google attack!
Google not only blocks the spam, but every result after it.
Sounds like an attack waiting to happen. Lets see, I really hate that blasted www.example.com site, ever since they totally ripped off my page! First, I'm going to mirror it here! Then I'm going to take that collection of spam I've been saving up all these years and attach it to my mirrored site. Then, if I can somehow push my site above in google page rank, they should not show up in any search and I have thwarted my opponent! YES! -
I think you're right
I'm going to start following your excelent example with my Slashdot comments.
Make money fast! Click here now!
I think it will help to improve the quality of my comments, and bring in more readers.
Your computer is not optimised. Optimise now!
However I'm a little concerned that people may find it difficult to follow my posts if I keep breaking them up with adverts and links.
Naked cheerleaders!
I guess it might also be a problem for users on high latency links.
Get your University diploma. Act now!
Who am I kidding? Fuck um, I'll just milk a single post for 6 page impressions per reader and overload it with adverts, animated GIFs and other shit. All I need to do is work out how to make Slashdot accept blink tags and embedded Flash, I can be just as leet as your site is every day!
Adverts got you down? Want content? Well we can't help! -
Do Not Mail versus Do Not Call (extensions)
With a Do Not Call list, one single entry covers all my phone extensions. Since the teleslimers will be comparing only the basic phone number, and not the number with its extension, against the list, by simply having my number without any extension in the list, a proper lookup will match and they can skip that number. None of my extensions will be called.
The issue is how to do this for email addresses. Many mail servers allow for "extensions" by having a certain special character such as "-" or "+" or "." followed by an "extension". By simply having the email account of the part before the separator, you automatically have every possible extension. Some people call this tagged email. And example would be jsmith-foobar@example.net where only jsmith@example.net would be in the list.
Many people even have their own vanity domain names, and regardless of what username is used before the @-sign character, they get the mail like the whole username were the extension.
For a registry to work, for at least those who are required to use it, it must meet at least these two requirements:
- Supports all user email addresses, including extensions
- Easy for the bulk mailers to compare their lists against
- The raw list itself must not be distributed
I looked at the registry run by the Washington Association of Internet Service Providers and found that the verification process only works one at a time. This makes their registry virtually useless. Of course, distributing the addresses in the raw will be worse, as it will get in the hands of spammers out of the country, and everyone will just get more spam because now spammers will have a list of address that are even more likely to have someone reading. And some will be mass mailing to such a list just to destroy the effectiveness of registering.
One option is to distribute an SHA1 checksum of each address. Then all that needs to be done on the mailer's end is to test each address by generating the checksum and looking that up in the database.
But even that has a risk, and I'm wondering if even that should be allowed. That risk is that spammers will run all their millions of email addresses through the process, and produce a subset of those who are registered, and then from out of the country
... they will spam the hell out of just those.In the end I think the only real solution is for a law that establishes two distinct networks (same address assignment base, but disjoint routing), one where spamming is allowed, and one where it is entirely prohibited under threat of jail time (for the executives in the case of corporations, LLCs, etc). Each ISP can then choose to service one or the other or set up dual but separate facilities to serve both. Wanna bet which network most will choose?
-
Do Not Mail versus Do Not Call (extensions)
With a Do Not Call list, one single entry covers all my phone extensions. Since the teleslimers will be comparing only the basic phone number, and not the number with its extension, against the list, by simply having my number without any extension in the list, a proper lookup will match and they can skip that number. None of my extensions will be called.
The issue is how to do this for email addresses. Many mail servers allow for "extensions" by having a certain special character such as "-" or "+" or "." followed by an "extension". By simply having the email account of the part before the separator, you automatically have every possible extension. Some people call this tagged email. And example would be jsmith-foobar@example.net where only jsmith@example.net would be in the list.
Many people even have their own vanity domain names, and regardless of what username is used before the @-sign character, they get the mail like the whole username were the extension.
For a registry to work, for at least those who are required to use it, it must meet at least these two requirements:
- Supports all user email addresses, including extensions
- Easy for the bulk mailers to compare their lists against
- The raw list itself must not be distributed
I looked at the registry run by the Washington Association of Internet Service Providers and found that the verification process only works one at a time. This makes their registry virtually useless. Of course, distributing the addresses in the raw will be worse, as it will get in the hands of spammers out of the country, and everyone will just get more spam because now spammers will have a list of address that are even more likely to have someone reading. And some will be mass mailing to such a list just to destroy the effectiveness of registering.
One option is to distribute an SHA1 checksum of each address. Then all that needs to be done on the mailer's end is to test each address by generating the checksum and looking that up in the database.
But even that has a risk, and I'm wondering if even that should be allowed. That risk is that spammers will run all their millions of email addresses through the process, and produce a subset of those who are registered, and then from out of the country
... they will spam the hell out of just those.In the end I think the only real solution is for a law that establishes two distinct networks (same address assignment base, but disjoint routing), one where spamming is allowed, and one where it is entirely prohibited under threat of jail time (for the executives in the case of corporations, LLCs, etc). Each ISP can then choose to service one or the other or set up dual but separate facilities to serve both. Wanna bet which network most will choose?
-
Re:REGISTRATION REQUIRED???!!!
Can't we at least be warned about such things?
Slashdot does a better job than most at warning readers that a linked-to site may require registration, or contain sensitive subject matter, etc.
However, you should realize, due to the nature of the internet, that there is no guarantee that the object you will find at this location[does not exist] will be anything like what it was when I gave you the reference by posting it here, or even that the site will let you access it at all.
In other words, yeah, registration sucks, but don't blame the messenger.