571 karma · joined January 1, 2012
There's an interesting article on Technical Taco, "Range header, I choose you (for pagination)!" The author makes a good case.
[1] http://www.w3.org/TR/html4/struct/links.html#h-12.1.2
[2] http://otac0n.com/blog/2012/11/21/range-header-i-choose-you....
What is the reasoning behind this statement? Resolving the hostname for the HTTPS site still requires DNS. Is it because DNS isn't encrypted, so a MITM could change the POST URL? That's an issue with unencrypted HTTP, also, so you couldn't safely send this header on non-SSL pages. You'd need a login link that goes to an SSL-protected page first, in which case this just adds an extra (no longer useful) step.
Since when does fair use require the preservation of ads or any specific portion of the content? Your argument dilutes the meaning and intent of fair use. Even the matter of being free or not has no bearing. The majority wisely avoided this area and fundamentally upheld the fair use rights of the users. The dissenting opinion confuses the issue by discussing licensing agreements, even going so far as to suggest fair use is somehow illegal.
I don't think the Persona project recognizes what a barrier to entry the lack of a reasonable discovery method really is. There are a host of potential issues:
1. For the alice@example.com identifier, it assumes that example.com has an A record. Many, many organizations choose not to have an A record at the top level, while still publishing an MX record to support email addresses.
2. If there is an A record, it assumes that there is a web server listening on port 443. If there isn't, /.well-known/browserid can't be retrieved. What is the fallback mechanism, and how does it affect our users if we adopt Persona in the future? What if this probe is flagged by an IDS, blacklisting the source IP?
3. If there is a web server listening on port 443, it assumes that it will serve resources for example.com. What if it doesn't and gets the /.well-known/browserid from the default host, which is an entirely different domain? What if this probe for an unsupported host is flagged by an IDS, blacklisting the source IP? What if example.com isn't the CN or a SubjectAltName in the SSL certificate? Is the certificate validated? Do I now have to purchase a commercial certificate for a domain that I never intended to be a web site?
4. When a user first enters an identifier, such as alice@example.com, it assumes this is not only a valid email address, but a valid login. What happens if a user has used an email alias in the fallback that cannot be used to authenticate in our system when we adopt Persona? What if the organization doesn't support Persona, and doesn't want its domain used in the fallback mechanism? Is there an inherent identity theft risk in using a fallback system? Can a rogue web developer create a temporary /.well-known/browserid and backend that will allow them to authenticate as anyone at the organization, then cover their tracks by removing the file?
All of these issues can be neatly solved with DNS discovery. If an organization wants to support Persona, let it publish an SRV record. If one doesn't exist, Persona should tell the user, "Your domain does not support Persona."
RHEL trees are forked off the Fedora repository, and released after a substantial stabilization and quality assurance effort.
Which adds a quote from the Fedora Project:
Red Hat Enterprise Linux is a commercial enterprise operating system and has its own set of test phases including alpha and beta releases which are separate and distinct from Fedora development.
And on that page[1] it states that RHEL6 is based on a "Mix of Fedora 12 Fedora 13 and several modifications".
Sorry to be pedantic, but that's significantly different than the Slackware model. Maybe it's just PTSD; I fled from RH in the old days onto the path that led to Slackware, so any comparison makes me touchy.
[1] https://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux?rd=R...
'sshfs_mount' is not really stable, any network failure will be troublesome'
To avoid trouble with remote backups and other long running processes, I always add the following to the end of ~/.ssh/config or /etc/ssh_config:
Host *
ServerAliveInterval 300Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent.
Consider using a dedicated key for each of those circumstances, set sane defaults in your ~/.ssh/config on all machines, and be very careful about what ends up in any of your ~/.ssh/known_hosts files, as they provide a road map to other destinations.
"Avian carriers can provide high delay, low throughput, and low altitude service."
"...only guarantees best effort delivery, loss of a carrier can be tolerated."
"...storms can cause data loss."
"Audit trails are automatically generated, and can often be found on logs and cable trays."
And probably most important:
"Security is not generally a problem in normal operation, but special measures must be taken (such as data encryption) when avian carriers are used in a tactical environment."
The only encryption method available is for the bearer to wear the ring, and Sauron has already cracked the key.
Avian carriers are only appropriate when it is feasible to have "persistent delivery retry, until the carrier drops." They're ruled out for this mission simply because there are no second chances.
Edit: I should add that my main environment is Linux running dwm in monocle mode on a 17" MacBook Pro. Noone could be more surprised than me that I would be intrigued by a new UI coming from Microsoft.
On an X11 environment, I can select some text and get the same results on the command line with something like:
xsel | qrencode -o - | feh -FZ
None of these commands are standard on any distribution, but you can easily install them or use alternatives. You can also make this an alias, hotkey, etc.[1] http://fukuchi.org/works/qrencode/
Edit: No need for temporary file
Either way, I think href should be a universal attribute (obviously, it wouldn't make sense on something like br). It offers a lot of flexibility and is probably no more subject to abuse than anything else. I don't see how browsers would have a problem implementing it. Just look at the 3D view of a complex page in the Firefox Inspector to get an idea of what they're already coping with.
Note that as an attacker, there's a high risk of exposure and identification in the scenario you describe, and that's a good thing. A well secured system shouldn't merely prevent attacks, it should also protect innocent users from suspicion (another reason why shared accounts are discouraged).
It's also a good idea to ensure that sshd has fresh keys that are unique to that machine. Hopefully, your images are installed without sshd keys, otherwise you'll have multiple servers with the exact same keys, which is considered bad practice. During initial configuration before deployment, you might want to remove the keys so that sshd will create fresh ones when it starts:
rm -rf /etc/ssh/ssh_host_*A developer is more likely to create better and more easily maintainable software if the target audience is assumed to be an ordinary user with no special system privileges. In my experience, when a developer has root and assumes everyone else does, deployment becomes a nightmare.