Read and monitor Oracle related blogs and news sources, all in one place.
A few things to report about Oracle Security after we have had a short break for familly holidays and also because of a lot of work being done over the last few months. It is nice to be busy in....[Read More]
Posted by Pete On 02/09/10 At 02:27 PM
If you install an Oracle Utilities Application Framework V2.2 or Oracle Utilities Application Framework V4 based product and you attempt to execute a batch/background process you may receive the error:
"User AUSER does not exist" or similar.
This is intentional as customer should configure the batch before using it. As part of the installation the only user provided in the product that is active and working is SYSUSER. This user is provided so that you can add other application users and SYSUSER is owned by the Oracle Utilities Application Framework. This means SYSUSER should NOT be used for any execution proceses as it will not have permission to the whole product.
To rectify the error above:
Essentially before running batch you should change the user to use for the permissions to a valid user for your site. Please do not use SYSUSER as it has mimited permissions and is owned by the Oracle Utilities Application Framework
As of this afternoon, version 11.2.1.3.1 of Oracle’s Exadata storage server software, is out in the wild. This is the first publicly available version of the 11.2.1.3 branch, a major release including a full OS image with an update to Oracle Enterprise Linux 5.5. A number of bugs causing cell server crashes and hangs have been fixed, including 9472035, 9870117, and 9722560.
Both storage server and database portions of this patch can be applied in a rolling fashion, avoiding entire database downtime. The minimum prerequisite version is 11.2.1.2.3, with an exception made for Exadata V1 devices at 11.1.3.3.0. If you’re running an earlier version, apply the 11.2.1.2.3 patch first.
The table below compares various URL shorteners based on how much they value service performance and the privacy of their users.
Here is the short version of the reading guide: a URL shorterner which gives a high priority to reliability, performance and privacy will use a 301 (“Moved Permanently”) response code, will not use cache control headers and will not use cookies. A URL shortener which gives high priority to its own ability to monetize its traffic by tracking users will do one or more of these things.
Here is how a few of the most popular shorteners perform by this measure (red is bad).
For the long version (and an explanation of how I came to create this table) read below the table.
| Service name | Cookie | Status code | Caching limitations |
|---|---|---|---|
| t.co (Twitter) | - | 301 | 5 min |
| bit.ly | tracking | 301 | - |
| tinyurl.com | - | 301 | - |
| goo.gl (Google) | - | 301 | 24h |
| wp.me (WordPress) | - | 301 | - |
| snurl.com | - | 301 | 10h |
| fb.me (Facebook) | (*) | 301 | - |
| twurl.nl | tracking | 301 | - |
| is.gd | - | - | - |
| ping.fm | - | 301 | - |
| p.ly | tracking | 301 | no caching |
| ff.im | tracking | 301 | (**) |
| u.nu | - | 301 | - |
| tiny.cc | tracking | 301 | - |
| snipurl.com | - | 301 | 10h |
| chkit.in | tracking | 301 | - |
| ur1.ca | - | 302 | no caching |
| digs.by | - | 302 | no caching |
Notes:
(*) Facebook’s service, fb.me, tries to set a cookie but its content is “locale=en_US” and cannot be used for identification. In addition, it sets the domain to “.facebook.com” in the Set-Cookie directive but since the response comes from another domain (fb.me) the cookie is actually never returned by the browser and therefore useless. It looks like this is a leftover configuration setting copied from the normal facebook.com servers. Defying all expectations, Facebook comes out as one of the most privacy-friendly URL shorteners.
(**) ff.im limits the cache to being “private” which means that your browser can cache the result but a shared proxy (e.g. your company’s proxy) should not cache it. Forcing each user behind that proxy to resolve the URL once. I magnanimously did not ding them for this, even though it’s sub-optimal.
Now for the longer explanation
Despite the potential it offers to stretch out our tweets, I wasn’t too impressed when I learned of Twitter’s plan to roll out (and mandate) its own URL shortening service. My fundamental issue is that URL shortening is made necessary by an arbitrary decision on Twitter’s part (the 140 character limit and the fact that URLs count toward it) and that it would be entirely within their power to make these abominations unneeded. Or, at least, much more rarely needed (when tinyurl.com came out, the main use case was to insert a very long URL in an email without having problems with carriage returns, not to turn third-world countries into purveyors of silly domain names).
Beyond this fundamental issue, my main concerns about Twitter’s t.co mechanism are that it reduces privacy and it demands that you break the HTTP specification.
From a privacy perspective, the issue is that anyone who clicks on these links tells Twitter where they are going. And Twitter can collect and correlate these actions. The easiest way for them (or any other URL shortener) to do this is to use cookies. Cookies aren’t often used as part of redirections, but technically nothing prevents them. So I wanted to see if Twitter used them.
[Side note: in practice there are ways to track your browser without using identifying cookies, not to mention simply using the IP address which works quite well on people who browse from home. Still, identifying cookies are the preferred method.]
From a specification conformance perspective, the problem is that Twitter announced that they would modify the Terms of Service of their API to prevent you from replacing the short URL with the real location once you’ve resolved it the first time (as of this writing they apparently haven’t yet made the ToS change). That behavior would be in violation of the HTTP specification if the redirection used status code 301 (“Moved Permanently”) which states that “any future references to this resource SHOULD use one of the returned URIs” and “clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server“. So I wanted to see whether t.co indeed returns a 301 (and asks us to violate the spec) or if they use a Temporary Redirect (302 or the new 307) in which case the specification would not be violated but other problems would arise (for example, search engines would not give you PageRank karma for such a link).
The other (spec-compliant) way to force a 301 to call back home once a while is the (strange but legal) practice of using cache control headers on permanent redirections. So I also wanted to see how t.co behaves on that front.
And then I decided to also test a few other services, which is how the table above came to be.
Related posts:
Lindsay blogged about the recent data breach report from Verizon last week. Alex Hutton, one of the authors has just re-tweeted DennisF's tweet that he has done a podcast about the data breach report . Enjoy! EDITED: I incorrectly added....[Read More]
Posted by Pete On 16/08/10 At 07:46 PM
RSS
Email