Slashdot Mirror

> Non-iphone users would try to use your website and be unable to. This will make your software look crappy.

BS. You can traverse any number of urls in your favorite browser that are not supposed to open for you, ever, because they are API endpoints, behind authentication wall, or any other reason. Nobody prevents me from deploying a customized http://thenewestiphonesonlytha... and just plain redirecting anyone and everyone whose user agent looks even slightly off. And if you got there by changing your user agent or using something like Links browser and cant render it, then thats kind of your problem.

That's because lazy coders put parameters as part of their URLs instead of using something like mod_rewrite to use real, human-readable paths.

http://www.website.com/?page=423&l=en
vs
http://www.website.com/en/products/

That's because lazy coders put parameters as part of their URLs instead of using something like mod_rewrite to use real, human-readable paths.

http://www.website.com/?page=423&l=en
vs
http://www.website.com/en/products/

I daresay you might get away with dialup if you use NoScript, block images, flash etc. But I wonder how many useable websites will be left if you do that?

http://m.website.com/

We need to train users to look for the browser padlock icon

But this can spoof that as well for many users (and even for Firefox users it might make the unwary feel safe).

We need to add browser extensions that heuristically detect credit card numbers being entered into unencrypted sites and to warn the user.

He also mentions methods for using IDN (Internation Domain Names) and wildcard SSL certificates to spoof HTTPS versions that look even more like the real thing than https://yourbank.com.some.evil.website.com/... (also mentioned here)

I'd like to see fewer people using self-signed certificates that train users to ignore SSL warnings.

I'd like to see that as well, but for that to happen you need to provide a way for low risk and not for profit sites to get certificates that are accepted by browsers but without the fees. I've set up my email (Webmail, IMAP and SMTP) with SSL certificates, but it took some searching to find someone who would give me a free SSL certificate and even then the issuer isn't in most browser's approved list. I'm protecting a small amount of traffic from lazy eavesdroppers, not protecting a financial institution - I don't need the expense and the insurance.

The fault lies partly with browsers too. Firefox, particularly, should never have toned-down the non-EV SSL user-interface --- sure, making EV special is fine, but allowing sites to spoof the SSL UI with a favicon is unacceptable. People have been saying this ever since Firefox 3 came out, but maybe now someone will pay attention to us.

HTTPS puts a blue background behind the favicon and the padlock and certificate domain in the status bar. What kind of favicon can ever spoof the entire blue background. More importantly, what favicon can ever spoof the status bar section?

reminds me of a story: i worked somewhere where the 'send out mailing list emails' was a script u hit in your browser, something like: http://website.com/domailinglist to send out all the emails..

turns out every night the webstats package would go thru the server logs and GET every page to find the title tag.. do'h

I had much the same thoughts on ad-hoc networking enabling file-sharing of an entire directory. I've yet to hear anyone say anything intelligent on the subject yet.


While they can perform a man-in-the-middle attack, that does require changing what keys a website uses (or possibly disabling encryption).


Well, the more troubling attack is disabling encryption. Most sites start out in HTTPS, and then have a link to the secure sight. If there's a man-in-the-middle, he can change all the links that send you to https://website.com/ to http://website.com./ Then just continue acting as a proxy and figure out which URLs should really be contacting the HTTPS sight, while continuing to talk to the client/victim in http. Sure, the victim could look down at what's supposed to be a "secure" website, but how often do you do that? I haven't in the past.. but I'll certainly try to more now.

I had much the same thoughts on ad-hoc networking enabling file-sharing of an entire directory. I've yet to hear anyone say anything intelligent on the subject yet.


While they can perform a man-in-the-middle attack, that does require changing what keys a website uses (or possibly disabling encryption).


Well, the more troubling attack is disabling encryption. Most sites start out in HTTPS, and then have a link to the secure sight. If there's a man-in-the-middle, he can change all the links that send you to https://website.com/ to http://website.com./ Then just continue acting as a proxy and figure out which URLs should really be contacting the HTTPS sight, while continuing to talk to the client/victim in http. Sure, the victim could look down at what's supposed to be a "secure" website, but how often do you do that? I haven't in the past.. but I'll certainly try to more now.

To get on the internet now i need to pay 15 dollars a year. Google caches most pages on the internet as it is so i can see them saying pay us 30 dollars a year and we will register your address and give you space to place it on the internet. then the browser companies will give them the ghttp://www.website.com/

>Instead of moving those configuration files out of the webroot!
What about
http://website.com/../../../etc/any_file_you_want?

These standards that they're setting up are good. They're not trying to force you to write something a certain way - you can go ahead and write it to depend on libthisisntincludedinanydistroexceptmine or whatever. What they're doing is writing a set of standards that you can choose to follow if you want for your distro or programs. The plus of this is that if the standard becomes widely accepted, companies will write more closed source apps for Linux (Photoshop, Winamp, etc.) because all users will have (apart from whatever a particular distro has set up) a specific way to access everything (like [almost] everyone has the GNU tools). Basically think of it as an expansion of the GNU tools to include any system function.

The benefit of this? well for those of us who support our own systems, probably nothing. But for companies that need to support Linux, it's huge. instead of having 500 different ways of doing something, you can support most users with just a generic system for all of this.

For me at home, it makes little difference. But at school I need to use Photoshop and InDesign for Journalism. If Adobe had made a Linux version, that wouldn't be a problem. But because there's no Linux version of InDesign and it doesn't work under WINE, I have a problem. Adobe's not going to make their programs for Linux until they have some standard for all of their stuff, but I need them under Linux.

I think they really need some sort of easy-to-use program that wraps around normal Linux installs for what they're doing. For example, I'm working (I'm not in a hurry; don't expect me to even release anything for a couple of years) on an application that builds support for just about any distro into a program. Give it a tarball (gzipped, bzipped, anything) with a specific directory structure, and it'll build a .deb, a .rpm, a .tgz (and/or tbz etc.) etc. The second part is a yum/apt-get/portage/etc. server that the user just needs to add to get the updates for that program (and the program itself). Finally, the third part is a user-end program that wraps around (insert package management system here) with this system. Say, for example, that I want to release a program with this system (assuming the user already has this last program). All I do is call my program with this and upload to the server. Then I tell the user to open this program and add http://my.website.com/url/to/packages to their list. The program adds /apt, or /yum, or /portage or whatever they need to the URL and adds correct formatting for that package management.

I think that's really what they're aiming for - one way for users of any distro to do anything necessary for support of their apps. Everything else can still be customized.